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. The years following that realization would take me through a wide range of interests and potential career trajectories ranging from Italian academic, to barista and coffee appassionata, to finally landing a steady customer service role at a tech startup in Portland. More than two years later, I still find myself at that very same startup.
It was my skills in writing and customer service that opened the door to the tech world. Thanks to the non-traditional nature of this support role, I was given the space to work on various data analysis and pattern matching “side projects” within my company. Eventually, I began to form a close working relationship with one of the engineers spearheading these data projects. As my affinity for pattern matching and analysis became more apparent, she and I began toying with the idea of having me program one day at work. I had tried teaching myself HTML and CSS a few times in the past, but none of those lessons ever really stuck. Now, with the prospect of a real programming job on the horizon, it was the first time that I felt my learning would amount to something. So, I jumped at the opportunity, and began teaching myself Ruby on Code Academy. Once I felt (somewhat) ready to put those learnings to practice, I was tasked a mini project at work that involved writing a script. And then I was given a second script to write. And then another one. Eventually, I was spending most of my side-project time coding, and ended up making the switch from customer support person to data engineer team member.
It’s now been more than six months since I’ve been a full-time programmer for my company. I’ve been working mostly in Ruby and Ruby on Rails, and have been able to assist in some pretty cool data projects, ranging from scraping info on the web to building internal dashboards for my team to interact with our data. I’ve supplemented my work with an online computer science course through EdX, and am hoping to start learning Javascript next. 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 from thus far 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.
- Don’t let a lack of “passion” stop you from jumping in.
Before I started programming at work, I was picking up and dropping “learning how to program” consistently for about 3 years. While I was haphazardly dabbling in online HTML and CSS tutorials, my significant other, also a developer, would be nerding out about his love for functional programming. Whenever I’d take a moment to reflect, I’d begin to calibrate my own level of coding “love” against his, and would quickly become discouraged by the difference. This was enough to stop me from learning. When I’d pick it up again, I’d immediately begin comparing myself to our company’s engineers. Again, I would grow discouraged, convincing myself that I didn’t nerd out about the same things as them, and that the technical “language barrier” was simply too steep. I didn’t spend my childhood tinkering with computers. I don’t lurk in the programming subreddit for funsies. Clearly, coding must have not been for me. So, I’d give up again. Rinse, repeat.
Ultimately, I stopped caring that I didn’t fit the mold of the life-purpose programmer. I decided to go full force into it anyway. I knew it was a useful tool, and that 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 like 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.
If a seeming lack of “passion” or excitement about programming is blocking you from giving it a try, my best advice would be to try it anyway! You never what it’s like unless you get into the weeds yourself. You might not feel a deep love for the craft right away, and, honestly you don’t necessarily need to. You might find that you like certain aspects of coding — whether it’s the challenge of building something or solving a problem, the constant, lifelong learning, or the immediate gratification that comes with seeing something you’ve written appear immediately on your screen. Who knows — you might even develop a passion for it after all! But you’ll never know if you don’t allow yourself the space to explore it.
2. Programming is a muscle: Exercise it every day.
This one is surely a piece of common advice, but it’s ubiquitous for a reason — it’s true! In my own case, I experienced two different ways of learning how to program. On the one hand, I was getting exposure and practice with Ruby forty hours a week at my full time job. In my spare time, though, I was also trying to learn C (and, more generally, computer science principles) through the Harvard CS50X course on EdX. Thus, in one area of programming, I was lucky to be able to devote a full time job to learning. In the other, presumably like most beginners, I didn’t have the luxury of endless time.
During my first few months with CS50, I would study in concentrated, infrequent bursts. I would take three days in a row and work tirelessly before and after work until I would a get stuck on a problem. Then, I would avoid it for a few days. Inevitably, the next time I came across the problem, I would have forgotten loads of necessary information, and would be forced to spend hours re-learning them. With the turn of the new year, I became determined to finish this class, once and for all. I told myself I would devote one hour every single day to the class. If after an hour I wanted to continue, I very well could. If I didn’t want to go on past that, then at least I would have studied for an hour.
This, as it turns out, was a much more effective method of learning in my spare time. First, it removed the mental barrier that led to my frequent avoidance behavior. My goal each day switched from “fixing this seemingly insurmountable and endlessly stressful problem” to “just spend the requisite hour today and move on with your night.” Most nights, I would actually spend two or three hours studying. More importantly, this method allowed me to keep the information fresh in my mind every day, even if I didn’t “solve” anything.
If you’re struggling to get programming to stick, and haven’t already tried this method of chipping away at it daily, give it a go! The more frequently you practice it, the stronger of a base you will be building, one step at a time. Try devoting half an hour, or even a full hour to programming each day. Ultimately, I think you might find that you’re learning more than you ever anticipated.
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 be familiar with the syntax to code in a particular language, 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, in the same way that learning how to structure and tactfully convey a piece of writing is essential. Both are important, but knowing only one will limit you.
As I mentioned above, one of my more effective strategies for learning programming this time was to follow up what I learned on Code Academy with the Harvard CS50x course on EdX. While I wasn’t thrilled to have to learn C, learning a lower level language forced me to be deliberate about my decisions (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 now 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 resources for your learning style.
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 was a visual/kinesthetic learner, having someone verbally explain to me what a line of code did ended up getting completely lost on me. I needed to see the output of each line of code in order to understand it. I needed pictures and diagrams and arrows to help me conceptualize things.
Find out what your learning style is, and seek out the resources that complement it. If you don’t know what your learning style is, try searching for an online test that might provide that answer for you. 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 meets on a semi-regular basis 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. It’s OK to break things.
This one applies more to working on larger engineering teams than for working on solo projects. Still, if you make any sort of headway on your programming journey, you’ll eventually encounter a time when something you’ve written will break things on production — -if you’re lucky, you might even bring all of production down. (Yikes!).
A few weeks ago, this happened to me at work (double yikes!). 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 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. But, rest assured that most, if not all programmers, have been there. You will fix it, and you will learn how to avoid that same mistake in the future. And you will be a better programmer for it.
7. Learning to be comfortable with being uncomfortable is a skill.
This one is perhaps the biggest lesson I’ve learned. The depths of programming knowledge are so, so deep, and the more you learn, the more you realize how much you have left to learn. When I was given my first dashboard project in Rails, I was an absolute wreck. I remember sitting with my manager one morning, after spending the entire previous day confused, with not a single line of code to show for it. As she tried clarifying some of the questions I had, I couldn’t focus because I was on the brink of tears. None of it made any sense to me. None of it was intuitive. I was convinced I was incompetent and that I would just never get it. Lo and behold, eventually, I got it. It took me four days to do what I it would take me three hours to do now, but the important thing is that I conquered it. And the next similar project, I was faster at it.
When learning how to program, you will inevitably feel lost at some point. You will feel every ounce of frustration build up inside of you. 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 got through it that first time, and surely, you’ll figure it out again. You might spin your wheels, but you’ll learn how to take a step back, hone in on right questions to ask, 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.
