Lessons From My First 6 Months As A Programmer
I am not a computer science major. I don’t have any formal training in programming. I spent my undergraduate days as a biology major, only to decide during my final semester that medical school was not for me. In the years following, I chased a wide variety of career paths, ranging from Italian academic to barista and passionate coffee person, until I finally settled on a customer service role at a tech startup in Portland. More than two years later, I transitioned within my company to our data engineering team as a full time programmer.
It’s now been more than six months since I’ve been a full-time programmer. I’ve been coding mostly in Ruby/Ruby on Rails, working on projects ranging from web scraping to building internal dashboards. Looking back, I’m amazed at how much a person can learn in just six months. While I still have so much more to explore, I have picked up some valuable tips that might benefit some other beginners out there. The first few pieces of advice I learned right away, but the last few took a bit longer to sink in.
1. Passion is not the same as persistence
Before I started programming at work, I was learning how to program off and on for three years. While I was dabbling in online HTML and CSS tutorials, I would witness my significant other, also a developer, nerding out about his love for functional programming. I constantly calibrated my own level of coding “love” against his, becoming discouraged by the difference. I also compared myself to the other developers at my company, convincing myself that I didn’t nerd out about the same things as them. Ultimately, though, I stopped caring that I didn’t fit the mold of the passion-filled coder, and decided to go for it anyway. At the very least, I would be empowering myself to pursue other interests with this skill in my toolkit. To my surprise, I found that I liked coding, and that, compared to my many other career attempts, this one made the most sense. I may still not have an all-consuming, capital P “Passion” for it, but it’s mentally engaging and allows me to pursue another passion of mine — learning. I never would’ve figured this out if I had given up yet another time.
2. Programming is a muscle: Exercise it every day.
At work, I was lucky to get exposure and practice with Ruby for forty hours a week. In my spare time, though, I was also learning C (and, more generally, computer science principles) through the Harvard CS50X course on EdX. For this class, I didn’t have the luxury of endless time like I did with Ruby. During my first few months with CS50, I studied in concentrated, infrequent bursts, often having to relearn information every time I came back to it. Eventually, I changed my approach and told myself I only needed to study for an hour a day, making my goals smaller and more attainable. Most nights I actually spent two or three hours studying. More importantly, this method allowed me to keep the information fresh in my mind every day, even if I wasn’t always “solving” something.
3. Learning the syntax of languages will only take you so far.
In many ways, I find learning how to program to be similar to learning how to write. You obviously need to know a language's syntax to code in it, in the same way that you need words and grammar to write. Words and grammar on their own, though, do not necessarily make someone a good writer. Similarly, I’d argue that learning how to approach and solve problems is equally, if not more important than getting the syntax down. As I mentioned above, one of the best things I did to learn how to code was to supplement my CodeAcademy with an intro to CS course on EdX (Harvard CS50x). Learning a lower level language forced me to be deliberate (which data type do I need? Why?). It helped me to frame software development in terms of pointers and memory allocation. Essentially, it led me to get to the core of what higher level languages like Ruby and Python do for you, and forced me to ask why? in addition to how?. If you’re looking to do more than just be familiar with coding, I highly suggest looking into computer science, data structures, or algorithms courses to supplement learning the languages themselves.
4. Find the best learning resources for you.
There. Are. SOOOOOOOO many resources out there. To help me choose which ones to use, I first considered how I learned best, and then sought out the resources that coincided with my learning style. Since I am a visual/kinesthetic learner, having someone verbally explain to me what a line of code is lost on me. I need to see the output of each line of code in order to understand it. I need pictures and diagrams and arrows to help me conceptualize things.
If you learn best by listening, dive into lectures or podcasts. If you need to see it to get it, look up diagrams and videos that use visual examples, or read online documentation for the languages you want to work in. If you learn by doing, pick up a book of practice problems and go to town.
5. Embrace the power of code review.
I can’t tell you how many things I’ve picked up from other programmers’ comments on my pull requests, or even from adding my own comments on some of the more senior programmers’ work. Simply getting exposure to other people’s code helps you to encounter differents ways of approaching different problems. If you don’t have the luxury of a programming community within your reach by way of your job, try finding a Meetup that gathers to work on projects together. Lots of online teaching platforms have discussion sections that allow fellow learners to bounce ideas off of each other. Perhaps there’s an in-person course that you can audit or enroll in at a local community college. Eventually, as you navigate your programming learning curve, the basics will become more obvious, and you’ll start honing in on some more nuanced coding practices. Looking at other people’s code, or having them suggest better logic for what you’re trying to achieve will help you be a better programmer.
6. Don’t be afraid that your code might crash existing programs at work
The first few times you commit code to a larger project will inevitably be daunting. The first time(s) your code breaks things will be even scarier, especially if it’s at work. But, rest assured that most, if not all programmers, have been there.
A few weeks ago at work, I merged in some code that incorporated some pretty expensive queries over a database table that had hundreds of millions of records saved on it. I also did not have an index on that column to accommodate this particular query. As you can imagine, I ended up bringing down our data-production side of things, and I couldn’t help but feel guilty about it. Luckily, I work with some pretty understanding engineers, and a few of them reached out to me assuring me that it’s all part of the process. If anything, I had just experienced a rite of passage — I even got a few congratulations. The important thing is that I learned from my mistake, and I took note of what technical improvements to make next time I was writing similar code (*cough* index).
7. Learning to be comfortable with being uncomfortable is a skill.
This one is perhaps the biggest lesson I’ve learned. The more you learn as a coder, the more you realize how much there is to learn. When I was given my first dashboard project in Rails, I was a wreck. I remember sitting with my manager the morning after I spent an entire day confused, with not a line of code to show for it. As she answered my questions, I couldn’t focus because I was on the brink of tears. None of it was intuitive to me, and I was convinced that I was incompetent because of it. Eventually, though, I got it. The next dashboard project I was given, then, became slightly less scary, and I became slightly more skilled at it.
When learning how to program, you will inevitably feel lost and completely frustrated. But you, too, will eventually figure it out. And then, you’ll find yourself in another situation where you’re confused, but you’ll become slightly less frustrated. You might spin your wheels, but you’ll learn how to take a step back, refocus, and move forward. Know not to blame yourself or your capacity to grasp these concepts if you don’t immediately understand them. Allow yourself the space to be confused. Eventually, you just learn how to be comfortable with being uncomfortable, and that if you’re stubborn and committed enough, you will get unstuck.
8. You can learn a lot in six months!
Mentally, six months feels like a short amount of time. Thinking back, though, I know eons more than I did six months ago. I look back at the post I wrote a month into learning, and laugh at my confused self. I had no idea what a Rails class even meant, let alone this “Active Record” business that was doing all this magic interaction with the database. Now, after having built six or seven mini dashboards for my team, ActiveRecord, and the Model-View-Controller paradigm doesn’t seem so intimidating.
You can really learn in a short period of time. Concatenate those smaller spurts of learning together, and all of a sudden, you’ll be years into programming.
Raquel Silva is a programmer by day, and a fledgling creative by night. You can follow her endeavors on Instagram and read her writing on Medium.