What’s the best way to learn to code? — Active vs Passive Learning

So, you’re learning to code… When you sit down at the computer, do you open an online course? A book? An IDE and start hacking away?

After all, what is the most effective and efficient way to learn to code?

Photo by Alejandro Escamilla on Unsplash

We live in exciting times and the ability to code can open a lot of doors. Never before have this many top notch resources been so readily accessible to anyone willing to roll up their sleeves and dig in.

So, what is the best way to learn to code?

The Two Main Strategies

The way I see it, there are two main strategies for learning to code.

The first, passive learning, involves the consumption of resources. By this I mean reading books, websites, and other blogs, or watching tutorials on Udemy, Coursera and YouTube.

The second, active learning, involves lots of practice. This can include building side projects, working through the freeCodeCamp curriculum or writing solutions to algorithm challenges at sites like CodeWars or HackerRank.

Which is better, active or passive?

The answer, in my opinion, lies somewhere at the intersection of the two.

I know, way to take a stance, right? Let me explain…

If you stick with the passive phase until you feel that you’ve learned enough and are comfortable starting to write code on your own, chances are you’ll never get to the active phase.

On the other hand, if you sit down and just start hacking away, not having taken the time to learn the basics, what exactly are you going to hack?

The Iteration between Watching and Doing

In my experience, learning to code is a very iterative process. Consider the following as what I think might be a typical ‘learn to code’ journey.

After learning some of the basics, you gather your courage and start building something of your own.

Shortly after you begin writing your own code, you hit a wall. At that point, you go search for a solution on MDN, Stack Overflow or any of the other great resources out there.

Once you have a solution, you go back to the project with your newfound knowledge and make your way past the previous barrier.

Until you hit the next wall. Back to MDN…

Rinse and Repeat…

Passive then Active…

Over and Over…

Get the point?

In my humble opinion, iterating between learning and doing while building something of your own is the best way to learn to code, but let’s back up a bit.

Photo by Syd Wachs on Unsplash

When do you know enough to cut the cord from the learning material and make that original leap into your own project?

When to Make the Leap

I’ve given this question a lot of thought lately with how it relates to my own situation…

I’ve been learning Angular over the last several months while working my way through the Free Code Camp data visualization and back end sections.

I started with Angular by doing some reading, then enrolled in this Udemy course. Max is an excellent teacher by the way, and I highly recommend his courses.

The problem is that there are almost 400 lectures and over 26 hours of content! Considering that I coded alongside the examples and took copious notes (not to mention my full time job and two kids!), this course would take me forever to get through.

After spending a few weeks working my way through most of the course and it’s examples, I started wondering — “do I know enough to try to build something??” It turns out, no, I really didn’t…

It wasn’t that I didn’t know Angular in enough depth. You don’t necessarily need to know something in great depth to get started, that’s where the iteration between active and passive comes in.

The problem was that I didn’t have the breadth of knowledge to start on my own. I had a hard time moving from the active phase to the passive phase because I didn’t know what I was looking for.

This led me to come up with the following guideline to use in the future

“Try to learn what you don’t know before you starting on your own…”

I know, sounds pretty asinine right? Let me try to explain with an example…

How can you possibly “learn what you don’t know”?

Let’s return to the Udemy course example.

I had worked my way through the components, data binding, directives, services and forms modules of Max’s course. Of course, I didn’t know everything about implementing them off the top of my head, but at least I had a general idea about how they each worked.

Photo by Tim Umphreys on Unsplash

In other words, I knew that these parts of Angular existed and generally what they were responsible for. That way, when I encountered a problem, I knew where to start digging for a solution.

For these topics, I knew what I didn’t know.

I had not, on the other hand, looked at the HTTP section of the course. So when I had to make an API call in my Angular app, I didn’t know there was a mechanism in Angular to handle this.

So I turned to something I already knew… I tried setting up a jQuery.ajax() call, not knowing that Angular had their own HTTP service.

Had I at least glanced through the HTTP module, I would have learned enough to know it existed, and therefore would have turned to the proper solution make my API call.

The Take-Home Lesson

My point here isn’t that I’m an idiot for trying to set up $.ajax() in an Angular app. Although if the shoe fits, right??

My point is that I would have been better off if I had gotten a broader understanding of Angular before I had begun. I didn’t need to know exactly how the Http service worked, just that there was one, and therefore, would have known where to turn to make that API call.

To sum it all up, the passive phase is great for exposing yourself to the breadth of a topic (concepts, ideas, etc), whereas the active phase will really hammer home the knowledge and give you a deep understanding of what you are learning.

The trick is finding the sweet spot where these two intersect.

Thanks for reading, I hope you were able to take away something of value for your time. Feel free to comment below either way.


This article appeared originally on crookedcode.com