Learning How To Learn To Code

I started learning how to code on October 11, 2016*—a day forever enshrined on GitHub as my first and only contribution for the year. Since then I’ve learned from a multitude of resources from tutorials to web courses to podcasts to blogs, not to mention of course my own projects.

But let’s be honest, a lot of that time was spent floating around learning pretty aimlessly!

And it’s definitely fair to say I’ve learned quite a few things about the process of learning itself. Now, I find myself taking an online course called Learning How To Learn (LHTL), and with a project to complete about the very topic. What an excellent opportunity to summarize the things I wish I knew when I started, helped along by some principles picked up in the class.

This List

As this is an assignment for the course I’m taking, this list will focus primarily on the learning methods that most resonated with me as they specifically apply to teaching yourself how to code. For the sake of brevity, I’m not going to include specific learning tools or resources (other than this course!), but a lot of them are listed in my learning list if you want to check them out. So with that caveat, here are…

My Top Tips & Warnings

TL;DR

1 — Have A Goal In Mind
2 — Crush Procrastination
3 — Practice Every New Thing, Then Practice Again
4 — Teach What You’re Learning To Someone Else
5 — Take Breaks Regularly
6 — Learn A Bit About Learning

1 — Have A Goal In Mind

When I decided to learn to code, there were so many choices to make without having a lot of information. How do you know where to start when there are so many blog posts, books, videos, etc. all giving different advice? Or if you come across something like the developer roadmap, how on Earth can you not feel overwhelmed by the many options ahead?

With the benefit of hindsight, I can say that I firmly believe that there is no right or wrong choice in the beginning, so there’s little point in stressing about this. The important thing is to pick one thing and set small goals that you can get specific about.

Now, inevitably, the more you learn about whatever you do choose, the more you’ll realize how little you actually know! It can be very easy to fall into various rabbit holes under the guise of “learning something new,” but ultimately these can act as distractions to the ultimate goal.

To that I say give 10% of your time to these distractions—it does help to build your understanding of the greater context of programming after all. But for the remaining 90%, focus exclusively on your goal, and don’t pursue new technologies, frameworks, libraries, etc. until you actually plan to implement them in a project you’re working on.

One thing that worked for me was to create a learning list. It served as a repository for remembering the things I’d already learned (which can be easy to forget when you’ve moved on to the next thing!) and a place to jot down the topics that could otherwise become a few hours of googling without much progress on my actual goals.

2 — Crush Procrastination

I’ve heard it said that time spent coding is 90% frustration and 10% feeling invincible. In my experience the balance might be closer to 98/2! That means every time I sat down to learn, I knew I was in for some pain, even if the end benefits were really worthwhile.

This is a prime source for procrastination! In LHTL procrastination is defined as the brain’s self-preserving response to tasks and experiences it perceives to be painful. It’s a very in-the-moment response—the brain isn’t thinking at all about the long-term benefits of being able to code, and instead just sees ‘hard’ and thinks AVOID AVOID AVOID!

Understanding and memory are built over time by regular and repeated practice, so getting through these moments is really key to making progress. The number one tip here is just to start anyway. When the task at hand feels daunting, you can focus on the process of work rather than the outcome you’re hoping for.

For example, if you’re working on building your first web page, rather than thinking about all of the bells & whistles you want to include, instead focus on opening your text editor and putting 25 minutes of work into the project. Oftentimes just the act of starting can get you into a state of flow, and then next thing you know 25 minutes have turned into an hour, and you’ve made some good progress.

3 — Practice Every New Thing, Then Practice Again

It’s an awesome feeling when you’ve just completed a code-along workshop or course and have a finished product to show for it. You look at how pretty it is, and the fact that it’s actually functional and think, ‘wow, I built this!’. You might even show it to some friends and get some great-feeling praise and encouragement.

This is the moment (yes, after patting yourself on the back for completing the course…it is an accomplishment after all!)…to go back and make the project again. From scratch. And without referencing the completed code. Then once you’ve done it once, give it a few days or a week and then try it again!

This is called deliberate practice; testing yourself in this way will solidify your technical skills in a way that following along in a course once simply cannot do. In LHTL this is referred to as “illusions of competence”—when you think you know how to do something from reviewing it shallowly (like coding along as you watch a pro make something). In the early stages of learning how to code this is a very easy trap to fall into, and I can say from personal experience that it’s pretty painful to have to repeatedly look up basic syntax and methods months and months after you know you “learned” them.

It may feel like a waste of time to do a similar project multiple times, but in my opinion it feels a lot worse to have to rely on Google for every new project you work on!

4 — Teach What You’re Learning To Someone Else

Memory is a tricky thing to master, but there are some tips and tricks you can use to help commit all of the new information you’re learning to memory. For example, reviewing the information in different contexts such as location or time of day can be one way. Another way is to change the method of experiencing the information—say you’ve been learning a topic from a book, maybe try getting some instruction from a podcast or video on the same topic. Involving different senses is another method: visualize a concept with a funny image, or bring in your tactile senses by writing some code with pen and paper instead of typing.

One method I’ve found that rolls all of these tips into one is to try teaching what you’ve learned to someone else. To help them understand, you might have to make analogies that you hadn’t thought of before, or write or draw something on a white board to visualize the concept. In doing so, you might even expose some gaps in your own knowledge that maybe were easy to gloss over when you were just on your own. If you aim to truly help the other person understand a concept, it’s likely your brain will have to do cartwheels through the information in your own mind to really be effective.

If you don’t have a captive audience at hand, it doesn’t have to be one-on-one instruction. You could write blog posts, record a podcast, or even just tweet something you learned. As long as you aim to explain the information to someone as if they have zero knowledge on the topic, it’s likely to have a very positive effect on your own learning.

5 — Take Breaks Regularly

All of the frustration aside, if you actually enjoy making things with code, it will be very easy to get into a state of flow…you’re working away on a project and look up to notice that three hours have gone by and you’ve not had a thing to eat all day! It’s a great feeling and can be quite affirming of the choice you’ve made to get into programming.

Even so, it’s very important to take breaks! Human physiology aside, your brain actually needs breaks to do its best learning. In an ideal learning scenario, you’re regularly going back and forth between the focused mode (i.e. the flow state working on your project) and the diffuse mode, when your mind is free and open to connect new information with the neural networks already established in the brain.

This is especially important if (when!) you get stuck on a problem in your code. Rather than banging your head against an issue for hours on end, work on it in a focused manner for 20-30 minutes and then take a break to do something completely different and relaxing. Go for a walk, take a shower, play some music, or even take a nap. Even when you’re not consciously focused on the issue at hand, your brain will continue to work at solving it in the background. When you return to the problem a bit later on, you very well may find a solution is not so elusive anymore!

6 — Learn A Bit About Learning

When you start learning how to code, the amount of advice can become overwhelming quickly. And the truth is, without knowing much about programming (which, as a beginner, is a given), it’s just about impossible to know which advice to even consider taking. That’s why I recommend getting a bit meta and learning a bit about how the brain is naturally wired to learn. It will put a framework around how you structure your studies and environment, which in turn will give you the best chance at learning effectively…instead of floating around from one resource to another like I did!

The Learning How To Learn course could be a great way to do that.

* To clarify, I should say this is when I started learning *this time*, as I’ve been coding in some capacity since I was 11 or 12. But prior to this date my interest in coding was pretty much exclusive to Myspace and Geocities sites 😂