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.
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…”.
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.