4 Ways to Learn Programming Topics
By: Amy M Haddad
All programmers have something in common. There’s a lot of programming knowledge to learn and we need a way to learn it effectively.
In many ways, learning to program for me has also been a crash course in learning effectively. As I set out to learn Python, I was also learning how to learn.
This post contains the best learning strategies I use to learn programming topics. I hope they can help you, too.
1. Get the Big Picture
There’s an essential first step when learning something new: get the big picture, which is a topic I’ve written about before.
Think of it as the bird’s-eye view of the topic you need to learn about, before you dive into the details and learn it.
Before diving into the details, get the big picture.
Watch a lecture or two on fast speed and get a high-level understanding of functions. While you watch, do the following:
- Write down important words.
- Note a few times in the video when important points are discussed (ie, at the 2:45 minute mark).
- Write an example of a function.
Understand when and why you'd use a function. Get familiar with how to write a function. Only then should you go back and take a more detailed look at the concept.
Breadth, then depth.
There are two reasons why the big picture matters.
First, you’ll know what to focus on.
Getting the big picture primes your mind: you know what to look for when you take a deeper dive into the topic.
It also helps ensure that you’re focusing on the right concepts at the right time.
There’s nothing worse than spending your time learning something that’s really not that important. Or maybe there are important details you need to know about at some point—just not right now.
The big picture gives you context, which will make the details much more meaningful.
And when you’re ready to dive into the details, there’s another learning technique you ought to try: spot checking.
2. Spot Check
“Pull out a piece of paper. We’re having a quiz.”
I remember feeling a pang of angst whenever I heard those words in school.
In retrospect, my teacher wasn’t trying to be sneaky. She wanted to see if we could recall the information we were supposedly learning.
Testing, as it turns out, is effective for learning because it involves retrieval: you have to retrieve learned knowledge.
In fact, retrieval is behind what psychologists call the “testing effect”, also called retrieval practice effect. The idea is that you’ll retain previously learned information better if you get tested on it, according to American Psychological Association, instead of just restudying the material "for an equivalent amount of time."
"[P]racticing retrieval makes learning stick far better than reexposure to the original material does," write the authors of the book, Make It Stick.
So, when it comes to learning, you're better off actively testing yourself than passively reviewing your notes.
For that reason, I’ve come up with a retrieval practice that I call “spot checking.” It’s when you randomly check your knowledge as you learn new material.
Like a pop quiz, the aim is to see if you can recall and articulate new information on the spot.
When it comes to learning, it’s one of the best techniques I’ve used.
Master New Material
I hit the “pause” button on my computer. It’s time to spot check my knowledge.
About a minute later I pause the lecture again. “Why would I use this type of function?”
As I’m learning, I constantly stop myself and check if I’m retaining the information.
These checks are completely random, like a pop quiz.
The questions I ask myself aren’t preconceived. I think of them on the fly, though they always pertain to the content I’m currently trying to learn or just learned about.
Nor do I pre-determine when I’ll stop myself and spot check my knowledge. However, I tend to use this tactic after I read a paragraph or two in a book, or watch a minute or two of a video lecture.
Randomness matters because the goal is to catch yourself off guard.
Can you recall a newly learned concept and explain in your own words?
If you can’t, then review it before moving on.
It’s Not a Race
Plowing through material without fully grasping it is like building a house on a shaky foundation. The end result is unstable.
The goal is to build a solid foundation of knowledge, since concepts tend to build on each other. Use the spot check technique to help you work toward that goal. The more times you revisit the material, the more familiar it becomes.
Critics may point out that “spot checking” takes time. They’re right; it does. In fact, learning takes time—and effort.
But you’re going to put the time in at some point to learn the information. Passively watching a lecture from start to finish probably won’t cut it.
So you might as well build strong mental models from the start. That’s what “spot checking” can help you do.
3. Learn Just Enough, Then Apply
Because you won’t retain it.
Instead, focus your learning.
Here's an example. Say you're going to focus on classes, so you start with the big picture. Then, you take a deep dive into the topic, using “spot checking” along the way.
Now it’s time to apply your knowledge. Do a few problems or exercises, for example.
This is the crucial point: learn it, then use it immediately. Only then, should you move on to another topic or go deeper into an existing one.
Now that you’ve learned about and had some practice with classes, add another layer. Learn how to extend a class, for example. Once again, start with the big picture and use spot checking when you take a deep dive into the topic. Then, apply what you've learned.
Putting knowledge into action is how you’ll solidify the mental models that you’re trying to build. It’s also how you’ll know if you’re really getting the information.
Waiting until the end of a course to apply your knowledge is waiting too long. It’s an overwhelming amount of information that you’ll surely forget by the end.
So when you identify resources to help you learn a topic, ensure that you also find some to give you practice.
4. Teach It
You’ve probably heard it before.
"If you want to master something," said Richard Feynman, "teach it."
But how do you teach something when you’re new to it?
I’ve got two solutions that I use myself—and neither involve stepping foot into a classroom.
The first is a variation of a learning tactic that Benjamin Franklin used, which I’ve previously written about.
The idea is to solve a problem, find a great programmer who’s solved the same problem, and study their solution. After some time has passed, implement the program once more using what you learned from studying the programmer’s solution. Then, compare your program to the one you studied.
The study process is actually a teaching practice.
The Real Test
Start at the top of the programmer’s program and write a comment for each line of code.
Explain what the programmer did and speculate why they did it. You’ll eventually use these comments as hints when you re-solve the problem.
In many ways, writing out comments is the real test. You’re teaching yourself.
The commenting process forces you to organize your thoughts and put words around ideas. It’s one thing to explain something to yourself in your mind. It’s something else entirely if you put words around it.
If you can’t type a simple explanation of a dictionary and why it makes sense to use it in this context, then you may need to take a second pass at it.
Teach Others as You Teach Yourself
The second teaching tactic is to write a technical article on a programming topic.
I assure you that you’ll learn a tremendous amount during the process. If you choose to publish it, you can also help others who are struggling with the same concept.
“But I’m just starting out,” you object. “How can I write an article on 'x' topic?”
That’s what I thought when I wrote my first technical programming article.
However, you definitely have something to offer, especially if you’re new to a topic. That’s because you bring a beginner’s mind.
Sometimes programmers who've been using a language or technology for years assume too much because they’re too far removed. They forget what it's like to be a beginner.
So explain one aspect of Git, for example, from your perspective—as someone who’s new to the topic.
The process of writing a technical article will benefit you in multiple ways.
For one, it’ll get you digging through the documentation as you take a deep dive into the details on a topic.
Being able to read and understand the documentation is an underappreciated yet important skill to have. You’ll get more comfortable using it as a reference to get the answers you need, since you’ll undoubtedly need to use it in your daily work as a programmer.
You can also better your “technical communication,” as Will Sentance, CEO of Codesmith, calls it. That is, using exact technical language when talking about code.
In my experience, writing can help sharpen this skill since you need to use clear language and exact terminology to explain concepts and processes.
Here’s an example from an article I wrote:
"Developers typically keep all of their CSS in an external stylesheet. In your HTML file, use the
<link> element to link to your external stylesheet, which contains your CSS. Inside the file, index.css, we have our CSS rules."
Writing this article forced me to slow down mentally. I had to check and double check the terms and processes. I had to be clear and specific.
The benefits of this practice are many.
You’ll better your understanding of a topic and solidify the information in your mind. You’ll also feel a boost in your confidence as a programmer: you know a lot more.
If learning seems laborious, then you’re doing something right.
“We’re easily seduced into believing that learning is better when it’s easier,” according to Make It Stick, “but the research shows the opposite: when the mind has to work, learning sticks better.”
The learning techniques explained in this post aren’t hacks. They’re not quick fixes.
Learning takes effort and time.
If you want to build solid mental models and better grasp the information you need to learn, try out the above techniques. In my experience, they help make learning stick.
← back to all posts