(This is a cross-post of a blog entry originally found here. It was written in 2014, but still holds up well today!)
A little over a year ago, I left the world of finance and corporate strategy and decided to join a start-up. Crazily enough, my new company was willing to hire me for a tech-oriented position despite the fact that I had almost zero experience coding – the last time I had seriously done coding work was in a programming class I took in high school.
But, thanks to a really supportive environment at work (having access to the collective knowledge of the internet didn’t hurt either), I managed alright. Now, I build out new features for our company’s products without too much worry that I’ll crash everything.
To start off this blog, I have a three-part series on my experience learning to code. This first piece shares some parts of my experience that have surprised me the most; if you are thinking of learning to code as well, hopefully this list will de-mystify some parts of this world!
- What’s motivating you makes all the difference. During my first couple of weeks trying to learn how to code, I was following resources like Learn Python the Hard Way and the tutorial on the Django documentation. For some reason, my learning felt a bit sluggish; I just didn’t feel like I was moving through the material as quickly as I could have. My learning curve really took a sharp turn upwards when I began working on actual projects for work. Part of this change was due to the social pressure and the chance to code with more experienced co-workers. But upon reflection, I think a more important factor was that this new context forced me to see how code behaved in a real setting. Learning about the basic building blocks of code in isolation is important, but actually struggling with the code in a more realistic environment helped me see how things connected and what kinds of questions were the “right” ones to ask next. I was definitely learning faster and deeper as soon as I got a real, work-related goal to work towards.
- There are obviously wrong ways, but few obviously right ways. When I started off, I thought any code I would write would be “wrong” and that it’d take me a while to learn how to write “correct” code. Turns out that much of the time, there’s a wide band of what would be acceptable code that solves a problem. There are ways that code can be definitively wrong: it could take way too long to do something, or it might suck up too much memory unnecessarily, for example. But a lot of the time, if the code solves the problem without causing too much mischief, it’s probably a fine, workable implementation. Learning how to optimize code is a long-term process, and at the early stages of learning how to code, there are more important low-hanging fruits to target.
- For popular languages, there’s a library for almost everything. Libraries (aka packages) are pieces of code that can be “imported” into another piece of code to provide some kind of functionality or help with some problem. That description is purposefully vague because the range of libraries available is staggering. For example, want to dabble in natural language processing? A quick Google search brings up three different Python libraries (having slightly different functions) on the first page of results. This link has a centralized list of over 600 libraries for Python alone! This is one way in which the most popular languages, including Python, are incredibly friendly to work with.
- Coding, at least in the early learning stages, is more like arithmetic than pure math. Coding seems like a daunting skill set to learn, especially when you hear about geniuses that were creating their own operating systems in middle school. At a practical level, however, and especially in the earlier stages of the learning process, coding is really a skill that can be learned like arithmetic (coding is to computer science, as arithmetic is to abstract math, if I may be allowed the analogy). Being comfortable with more quantitative and/or logical work is helpful, but no knowledge of proofs is needed. Unlike arithmetic, however, the coding skillset is a lot bigger and filled with many more tools and languages.
- “Spinning your wheels” on a problem by yourself is sometimes (most of the time?) bad for the learning process. There is a lot to be said about struggling with a conceptual problem, and in so doing deepening one’s understanding of the material. This is not necessarily the case with coding. A lot of times, problems that seem completely intractable are due to very silly, minor reasons; spending an hour trying to figure something like that out is frustrating, de-motivating, and ultimately not even that educational. In almost every situation where I spent a long time trying to figure out a bug, a patient and more experienced friend was able to spot the solution very quickly, a solution that was either very simple or one way beyond my understanding of a seemingly unrelated topic. When just starting off coding, triaging big bugs from small bugs is difficult, and this is where having an experienced friend’s help is incredibly useful.
The more you learn, the more you realize how much more there is to learn. This is probably true for any subject, but I always find it humbling to experience again that feeling of “Wow…I know so little about this part of human knowledge!” Once I began to feel a bit more secure as a programmer, I began to understand the limits of my own knowledge and what else there was out there to learn about in the tech world. The sheer range of topics in the general discipline of “computer science” is intoxicating to think about, and even a bit paralyzing at first. However, knowing the basics is also empowering: technological feats that once seemed absolutely magical suddenly seem mentally approachable, and potential ideas for that day when “I’ve learned how to code” suddenly seem much more feasible. Now that I know more about coding and computer science, I find learning about new topics in this discipline incredibly enjoyable.