They are spending a lot of time. They’re sacrificing a lot of time and their mental energy on learning by tutorials. Or maybe they’re building applications and watching videos.
They’re putting so much time and effort into things and learning but they are not doing much more than that.
They’re just hoping that by putting a lot of time. By putting their blood, sweat and tears into this it’s going to be enough to get them their first job.
And the truth is that hope or hoping is not truly a strategy.
You need to be systematic not only about your overall approach but also about how you learn.
So, if you’re just going to sit down for 8 hours and try to go through a textbook. Or sitting down and watching a Youtube video for 5 hours.
No matter how good that tutorial is. No matter how good that book is. Unless you have a strategy for learning a specific strategy and understanding psychology of how to remember things.
For example, how to get the most out of your learning. Then you’re simply not going to be as efficient with your time as someone else who understands those basic principles.
So, that’s what I will be covering in this article.
By the way, if you’re new here, I’m Peter Mukundi and I help people get their career started in programming.
So, if you’re looking to teach yourself how to code and land your first job as a software developer, I highly recommend checking out my blog from time to time for tips to take your career to the next level.
So, with that being said let’s just dive into the 5 learning strategies.
Proper ratio of active versus passive learning
The first learning strategy is really knowing the sweet spot for you between active and passive learning. Passive learning would be where you’re learning passively.
So, you’re reading a book. You’re kind of just sitting there, laying back, reading the book.
Maybe you’re watching tutorial where you’re not really actively participating. Some people call this conceptual learning.
You can look at that as the opposite of active learning or hands-on learning. Where you’re actually applying the knowledge or you’re learning and using it to build an application.
Maybe you’re doing some coding problems or some white boarding and interview problems.
These two are sort of diametrically opposed in terms of how you interact with them. One is like I’m to do something versus one is sort of I’m just going to lay back.
And you have to make sure you find that sweet spot because if you are 100 conceptual learning then you are going to run the risk of not being able to actually problem-solve.
Like actually go to a code editor and start applying the knowledge you’ve learned.
And the opposite is true.
If all you’re trying to do is just put code in a code editor but you don’t know the basic syntax of a programming language.
Or you don’t know the basic concepts. Definitely, there’s something that’s going to be lacking and your growth is going to slow down.
So, you have to understand that sweet spot. The sweet spot really kind of depends on where you’re at.
I’d say if you’re earlier on in your career or if you’re early on in your self-taught journey you’re going to want to focus more on the conceptual.
Like 2 to 1 ratio I think is okay. Meaning for every 2 hours of conceptual learning you want to have 1 hour of active learning.
Where you’re actually manipulating code in a code editor.
Meaning 1 hour of passive learning to 1 hour of active learning. You want to keep it about equal or about the same.
Later on this could really change drastically. I think once you’re into your career and you’re really just in the thick of it I think that ratio could be 4 hours of active learning versus 1 hour of passive learning.
But again it really depends on where you’re at. As you grow in your career it can swing way back to the 2 hours of passive versus 1 hour active.
This could be the case when maybe you’re making a big push to learn a framework that just came out or whatever.
Just keep in mind that there is a sweet spot. And you want to find it for yourself.
The second learning strategy is really important as well and that is to apply spacing to your learning. A good example of this is when you want to learn a new concept in programming.
Let’s say you’re learning c-sharp and you want to learn about dependency injection. So, you go on Pluralsight which is a fantastic site to get extended learning once you’re in your career.
And you’re learning dependency injection and there’s like a 5 to 7 hours course and you want to just cram it all today.
However, the course is designed to take 7 hours learning it. Or maybe over the course it could be 8 or 10 hours.
But instead of taking a few breaks, you just want to cram it all today because you want to get dependency injection gentleman check mark.
However, what the studies have shown is that, instead of cramming it all in one day, it’s better to take that 7 hour course and spread it out over time.
So, if you take that course and spread it out 1 hour over each day, you’re more likely to retain this information.
And part of the reason why I think that this occurs is because when you’re cramming it all in one day it seems like you’re making momentum.
But the actual truth is that when you have spread this out over time is that you’re going to be revisiting this each and every day.
And even more importantly you’re going to be forgetting knowledge each and every day.
So, day 1 you get this momentum built by covering basic principles of dependency injection and you’re also taking as 8 hour break to sleep and eat.
Or just doing whatever you have to do and then you’re coming back to the next day and you realize you may have forgotten something.
So, you have to sort of remember things and that forces your brain to put certain things in long term memory.
At least that’s the theory but I found that to be true as well.
So, the number one rule here is to avoiding cramming whenever possible but really try to space things out over time.
The third learning strategy that I cannot recommend enough is teaching concepts or re-explaining concepts that you’ve just learned.
So, if you’re knee-deep in learning some concepts right now and you think you got it down. The best way to really test your knowledge is to write a blog post about it.
And explain what you just learned in detail or even writing a journal entry.
If you’re in that sort of group you could sort of explain what you’re learning and get honest feedback on your understanding of the concept.
This is because when you have to formulate an idea, you learn so much more.
And I definitely learned this way myself now that I’m mentoring and coaching people to become software developers and start their career.
I’ve really learned that many of the concepts I thought I knew down really well, there were some gray areas. Or there were some areas that I really didn’t know or grasp.
This is because when people ask me something like, why did you choose that decision or why did you make that decision, I had to really think deeply about it.
So, I explained to others and you could do that through a blog post or journaling or even helping others in a social community of some sort.
Keep track of questions
The forth learning strategy comes directly from my experience of learning programming. And that is to keep track of all the things that you have questions about.
I always recommend you keep track of all your “whys”.
And this is something I found happening a lot when I was watching tutorials or reading books.
Like when you’re reading through a book and you’re making good momentum, you don’t really want to stop when you have questions.
You don’t want to go off on it and rabbit chase on Google because you’re making progress with the book.
And this happens all the time.
You’re definitely going to have some base underlying questions you don’t know about.
And the best thing you can do is to have a legal pad that you keep next to your desk or maybe a text editor or a Google document with all the questions that you want to ask that are really bothering you.
But you can’t answer right now and maybe you can push it off for later.
And maybe the instructor of the course you’re watching or the book you’re reading isn’t explaining it.
You can go off on a rabbit chase for a half hour or an hour. Whatever you feel is comfortable for you.
The problem I see with a lot of people who don’t keep track of what they don’t know, is that when they get done with a tutorial or when they get done with a book, they just have all these things in their head that they remember they didn’t know.
And they feel very frustrated.
But if they could just clarify say, “there’s like 5 things that I really wanted to learn” then they can spend the time after their book is done or after the tutorial is done, researching on the questions they had.
Then, they’re probably going to feel a lot more confident moving forward that at least they have some understanding about what’s going on.
So, keep track of what you don’t know and be pretty diligent about this.
I like a legal pad next to my desk but you can easily use a Google Docs or maybe an Evernote document as well.
Rest and recover
The fifth learning strategy is really a foundational principle for all effective learning. And that is knowing how to rest and recover.
I see a lot of people out there who are going the hustle and grind route. And I totally respect that.
And they’re talking about how they’re working 12 hours or studying for 12 hours. Maybe they’re working a full-time job. They’re sleeping 4 or 5 hours a night.
They’re putting their heart and soul into this. They’re putting their sweat, blood and tears.
And like I said, I totally appreciate that more than anyone else but you also have to understand that resting and recovering, meaning taking time off to sleep.
Or just taking time off to think about some other things like hanging out with friends and doing normal things is so important for you to retain as much information as possible.
And also it’s generally good for you in a long-term perspective because if you’re going to be studying for a long period of time, which takes more than just a few weeks, you want to make sure that you are looking at this long term.