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

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?

We live in exciting times and the ability to code can open a lot of doors. Never before have so 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?

Learning to Code Strategies

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

One strategy, 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 best for learning to code, active or passive?

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

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 enough to start coding 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 MDNStack 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 Stack Overflow…

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.

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 the course.

The problem is that there are 248 lectures and over 16 hours of content! Considering that I coded alongside the examples in the course 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 know what you don’t know before you starting on your own…”.



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

How can you possibly “know 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 these topics off the top of my head, but at least I had a general idea about how they each worked.

In other words, I generally knew what I didn’t know about them. That way, when I encountered a problem, I knew where to start digging for a solution.

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 it to 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, in the unlikely event that anyone is still reading, 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.

I hope you were able to take something away from my musings, please feel free to comment below either way.

-Jeremy

Learning to code? Avoid Workload Paralysis

There’s a lot to consider when learning to code.

A LOT!

In fact, saying “there’s a lot to consider” is a huge understatement. Chances are, at some point you are going to get overwhelmed with trying to find the best path forward.

With that overwhelmed feeling comes the sense of workload paralysis. You know, that feeling where you have way too much on your plate and you can’t possibly picture a way to get everything done.  So you just sit there, shut down and stare at your monitor like a deer in headlights…

Sound familiar??

The Triggers

This has happened to me several times while on this ‘Learn to Code’ journey and in looking back, I’ve identified two main triggers for it…

Either a) I’ve read the opinions of too many people, each giving different advice on how to approach learning to code or b) I’ve let my mind to wander from the task at hand and allowed the big picture overwhelm me.

Granted, these are what I’ve identified as my triggers. Yours could be different, so it might be worth a little time reflecting on the situations that send you into paralysis.

For the time being, let’s dig a little deeper into mine…

The Trap of Too Much Advice

Reading advice is a good thing, it can help you navigate your journey more efficiently. But taking advice from too many people, all with opposing views can be paralyzing.

Or worse, you’ll start resembling this cat trying to catch a laser pointer.

via GIPHY

That could get ugly pretty quick… But what to do about it?

Make it your mission to find someone whom you trust, and who is offering advice on the exact goals you have set out for yourself. Doing this will keep you focused on your own path, not someone else’s…

Use this advice to draw a path forward and trust that if you maintain that path, you’ll eventually reach your goals.

Most importantly, write the plan down.  I’ll discuss this more below, but if you try to keep this all in your head you’re destined to become that cat…

The Big Picture

Don’t get me wrong, I’m not saying that you shouldn’t have perspective of the big picture.  But if you allow it to overwhelm you, you’ll lose sight of the path you’ve have carved out for yourself.

As I mentioned above, use the advice of someone you trust to create a plan.  A key part of this, is writing it down and approaching it in a step by step manner.

All you really need for this is a pen and a piece of paper, but if you prefer to keep a digital copy, Trello or even Google Docs are decent options (yes, I know there are plenty of storyboard and goal writing apps out there, but that’s beyond the scope of this article).

Once you write everything down, you no longer have to spend the mental bandwidth on remembering the entire plan.  You can clear your head and focus on the next step.

Again, allow yourself to look at the big picture but ALWAYS keep your focus on the next small task in order to maintain momentum on your path forward.

As alway, I hope this was helpful, feel free to leave comments below.

Now go build something awesome!!

-Jeremy