Programming is hard .
. The only folks who say otherwise are the ones who have years of coding experience under their belts. It’s okay to be overwhelmed! There’s a lot to learn and you’ll probably forget things as quickly as you learn them. Trust me: that’s normal.
But just because it’s normal doesn’t mean that it isn’t frustrating. Truth be told, learning how to codecan be extremely stressful if you don’t approach it with the right mindset and attitude.
You want to learn that new language or library or framework as soon as possible, right? That’s understandable. Fortunately, there are a handful of tips that can help you to better retain all of that heavy programming information that keeps flying in one ear and right out the other.
No More Cram Sessions
Nobody wants to hear it, but cramming is the worst way to learn how to program. If you’re anything like me, cramming was your modus operandi all throughout school and university. It’s the only way you know how to study.
But learn from my mistakes: the more you try to cram, the less you’re going to remember . That’s pretty much true for any knowledge-based subject, but it’s especially true when it comes to programming.
The basis of this claim comes from a 2008 studyby the University of California, San Diego:
Students perform better when they space their study sessions rather than when they try to cram everything into their noggins during one sitting.
Why? Most likely due to the serial position effect:
Serial position effect is the tendency of a person to recall the first and last items in a series best, and the middle items worst.
In other words: in any given study session, you’re more likely to retain the information that you learned near the beginning and the end of the session and more likely to forget the information from the middle of the session.
You want to maximize the number of beginnings and ends. That’s why it’s better to have multiple short sessions instead of a few long sessions when it comes to learning and absorbing new material.
The next time you sit down to learn code, take it one topic at a time and take a short break between each topic. (Just make sure to prevent your breaks from turning into procrastination!)
Review, Review, Review
Another reason, why cramming is antithetical to long-term knowledge retention is because memory fades over time. This isn’t always true — I’m sure we all have a few childhood memories that will never disappear — but it seems to be the general case for memories that aren’t tied to emotion.
There is some debate whether memory itself decays due to time ( decay theory) or simply gets pushed out and replaced by new memories over time ( interference theory). Whichever theory you subscribe to, the result is that older memories are more likely to fade away.
This is where review comes into play.
Think of it like walking through a forest of memories. Every time you want to access a memory, you have to trace the neural pathwayin order to find it. Each time you trace that memory, the pathway gets etched in a little more — just like how a dirt pathway naturally forms when people walk the same path over and over. If you stop walking the pathway, it can fade away and the memory ends up lost somewhere in the forest.
Setting aside all of the pop psychology, here’s the takeaway: when it comes to programming, it’s not enough to learn a topic just once or twice. You have to revisit it dozens or even hundreds of times. Each review etches that topic into your brain a little bit deeper.
I know how hard this can be if you’re a natural crammer, but you’ll be surprised how fast you start retaining material once you make an effort to review it regularly.
Use Several Different Resources
The toughest aspect of programming — at least for brand new coders — is the sheer breadth of details and nuances that need to be internalized. Until that internalization happens, you’re going to be in a perpetual state of head-scratching.
Depending on the language, you’ll need to memorize hundreds of syntax rules (e.g. keywords, semicolons, whitespace). Some languages are stricter, others are less so, and still others have their own unique approaches to syntax that aren’t used anywhere else. All of this can be confusing if you have no prior coding experience.
Not to mention all of the conceptual information that transcends individual languages. Topics like object-oriented programming, entity-component systems, and observer patterns can really make your head spin the first time you try learning them.
I’ve shared this illustration before, but it’s so poignant that it bears repeating:
Suppose someone showed you a photograph of a statue. It might provide enough of an image for you to get an adequate sense of the statue, but you wouldn’t get the whole picture. A zoomed-out photo would lose intricate details while a zoomed-in photo would lose a sense of perspective.
However, with each additional photograph, you can really start to see the fullness of the statue in texture, in size, in detail, from front-to-back, side-to-side, and top-to-bottom.
Learning to program can be surprisingly arbitrary. Everyone might praise Resource A as being the best way to learn Language X, but maybe it makes no sense to you. Maybe everyone hates Resource B but you take one glance and it makes perfect sense! As for someone else, maybe they zone out when studying Resources A and B but benefit greatly from Resource C.
That’s why it’s so important for you to be willing to consume all kinds of resources out there. Everyone learns in a different way. If you’re having trouble with a particular topic, search around for another resource. Maybe that one will be more suitable for you. Maybe not.
Even if you think you understand certain topics, it’s possible that there’s more to learn about it. It’s also possible for someone else’s explanation to solidify the concept in your mind for good. You never know, so why not consume as many resources as you can?
Teach Concepts as You Learn Them
There’s a beautiful concept in programming called rubber duck debugging, which describes the technique of explaining one’s code, line by line, to an inanimate rubber duck. It’s used when a particular segment of code is broken, but there’s no obvious reason for it.
Strangely enough, most programmers have a “Eureka!” moment in the middle of explaining the code as they suddenly see where the error in coding logic occurs. Verbalization triggers a different area of the brain, forcing you to see the problem from a new angle.
This concept can also be used to help you learn new material. You may have come across this popular quote that’s often attributed to Albert Einstein:
If you can’t explain it simply, you don’t understand it well enough.
With the exception of some fields that deal with advanced theoretical knowledge, this saying holds true. The more you understand a topic, the better equipped you are to explain it in such a way that someone who has no knowledge of said topic can still come to understand it.
The opposite of this is true as well. As you try to teach a topic, you’ll come across certain concepts that you can’t seem to explain in a clear manner. Not only is this an awesome way to diagnose weaknesses in your knowledge, the actual process of finding the proper explanation can help solidify the concept in your mind.
It’s called learning by teachingand it’s basically a twist on rubber duck debugging.
Now, I’m not saying that you should actually teach others; rather, every new programming topic that you learn, try teaching it to a rubber duck (or an invisible friend). It may feel silly at first, but you may find it incredibly fruitful when it comes to memory retention.
Deliberate Practice Makes Perfect
The notion of talent is complete rubbish. Nobody exits the womb as a world-class violinist, wrestler, or programmer. Sure, some people might be more inclined towards certain disciplines, but talent without experience is useless. Similarly, hard work is always more valuable than talent.
That being said, not all forms of hard work are equal . Malcolm Gladwell coined the infamous 10,000 Hour Rule, which says that you must invest at least 10,000 hours into a subject in order to become a master at it. While the sentiment may be true, many people misinterpret what he was trying to say.
Long story short, a 10,000 hour commitment doesn’t actually guarantee mastery. You know the saying: “Practice doesn’t make perfect. Perfect practice makes perfect.” In order for it to be meaningful, practice must be intentional. Mastery can only be attained through 10,000 hours of deliberate practice.
How you practice matters far more than how much time you spend practicing.
Reading is passive. Watching YouTube lessons is passive. Listening to podcasts is passive. As a newbie coder you might be tempted to flutter from tutorial to tutorial, tackling subject after subject without actually applying any of that knowledge in a practical way. Resist this temptation.
It’s one thing to understand an example before you, but it’s another to synthesize a solution from scratch. If you want to speed up the learning process, you must be willing to be active instead of passive. Active practice is the only kind that matters in the end.
Experiment With Personal Projects
For me, homework was the worst part of school. It just seemed like an elaborate ploy to kill fun and keep students busy — which, to be fair, was sometimes true. But now that I look back, the importance of homework finally makes sense. It forced me to apply newly acquired knowledge in an active way.
If you’re enrolled in a programming class, don’t underestimate the efficacy of homework. Take it seriously, always treating it as a chance to further cement what you’ve learned into long-term memory.
But many times, homework still isn’t enough. (And if you’re learning how to program on your own without an actual instructor, you probably don’t have any homework to begin with.)
What’s the solution? Create a couple of throwaway side projects!
Think of a few project ideasthat you’d like to implement. For absolute newbies, you might consider a game of Tic-Tac-Toe or Hangman. For seasoned programmers trying to learn a new framework, try coding a simple mobile app or web game. As long as it interests you on a personal level, go for it!
The beauty of this approach is two-fold.
First, it’s more likely to hold your attention. Studies have shown that students learn better when they can pursue topics that interest them. That’s exactly what a personal project offers. You have an end goal that you actually want to achieve, thus you’re more likely to retain the information that’ll get you there.
Second, there’s no pressure for you to succeed. While success would be nice, the lack of formality allows you to be experimental and creative. You’re inevitably going to run into issues, but it’s more like playing with Lego than it is homework. It’s more fun and not as stressful.
Relax & Bookmark Everything
The truth is that no programmer remembers everything they’ve learned. Even after you’ve been working with a particular library or framework for a while, it’s not uncommon if you can’t recall every function or variable off the top of your head.
In fact, trying to memorize everything might just end up being a huge waste of time and effort. Reference sheets exist for a reason. Why commit an entire encyclopedia to memory when you can just flip it open whenever you need it? The same is true for programming APIs.
So, when to memorize and when to reference?
When it comes to conceptual material, always internalize it to the best of your ability. By that I mean understanding the theory even if you can’t convert it into actual code (and theory should be clear enough to you for you to teach it clearly).
For everything else — such as specific function names, parameter lists, or even language quirks — I wouldn’t worry about committing to memory . Feel free to defer to a reference sheet. Sometimes you’ll reference something so often that you end up memorizing it. If that happens, fine. If not, that’s fine too.
Personally, I have hundreds of Internet bookmarks to various APIs, guides, and tutorials. If I need to implement some kind of pathfinding algorithm, I might reference a guide to help me get it coded before forgetting about it again. It helps to understand the underlying concepts, but I try not to fret about implementation details.
Final Thoughts
I’ll repeat it a million times if I have to: programming is hard and it’s okay if you struggle with it. I’ve been programming as a hobby for over a decade and I still find myself intimidated when I have new concepts to learn.
Don’t beat yourself up if you can’t remember everything right away. The above tips will hopefully prove helpful to you, and even if they don’t, you can always rely on bookmarked references as a last resort.
Do you find programming difficult? What kind of tricks and tips do you know that might be helpful to newbie coders? Share your wisdom with us in the comments below!
Image Credits: Binary Programmer Via Shutterstock, Memory Eraser Via Shutterstock, Obfuscated Code Via Shutterstock, Rubber Ducky Via Shutterstock, Keyboard Typist Via Shutterstock, PHP Source Code Via Shutterstock, File Folders Via Shutterstock
×
Thanks for subscribing. We've sent you a confirmation link you'll need to click on to verify your email address.
Sign up to be notified of new articles on the topics discussed:
Join live MakeUseOf Groups on Grouvi App Join live Groups on Grouvi
Learn New Skills
423 Members
Self Improvement
393 Members
Productivity Tips
354 Members
Breaking Bad Habits
160 Members
Living Healthy
97 Members
Comments
Post a Comment