Learning styles vary from person to person. Regardless, many of my fearless leaders/instructors/mentors have strongly advocated for these approaches to learning how to code. They wanted us to succeed, and they gave us the tools to do so.
My classmates and I — a melting pot of different learning styles and backgrounds — all used these tools.
(Most of the time. When reminded. Frequently. Sorry coach.)
But yes, we all graduated right on time!
Without further delay, here are the methods I wish I knew on day one of developing as a Software Developer.
#1: Stop Taking Extensive Notes
Why?
This is the number one biggest time-waster I succumbed to while learning how to code. Like most, I went through many years of traditional education where good note-taking is emphasized. While I am still a supporter of taking notes, it is not the most effective way to learn how to code.
But isn’t handwriting notes linked to better learning outcomes?
Yes, and I will get to that — but not for every case when it comes to coding. Learning how to code can’t be approached in the same way one would learn in a standard lecture.
Trust me. When I discovered the ways I could be more efficient, I still felt a deep hurt reminiscent of a teenage breakup when I retired my ratty three-ring binder.
How?
I wouldn’t recommend doing away with notes completely! I encourage you to utilize methods that will save you time and make your learning more efficient and effective.
Github Gists
I replaced the binder with GitHub gists and focused on jotting down big concepts — not carefully documenting every little detail. No more carrying around notebooks. If you have internet, you can access your gists. How convenient.
Gists are great for notes you want to frequently reference later. You’ll be able to do a quick command-f instead of flipping through pages and suffering the burn of a debilitating paper cut.
Quizlet
Another method I’ve used to build competency is Quizlet — a website where you can create stacks of e-notecards.
I really love this one because testing yourself ensures that you know it rather than just skimming notes and accepting your fate (more on false competency in a bit). I also use their mobile app to study in place of my mindless, glazy-eyed social media scrolling sessions.
#2: Learn Content in Small Chunks
Why?
You’re probably not a JavaScript master after reading Eloquent JavaScript from cover to cover.
How much would you truly retain and be able to use? Likely not a whole lot. If you can, color me mega impressed.
How?
Break up your content
As you are learning something new, learn just enough to be able to do something with it. Once you got it down, repeat with a new piece of content.
Even if it’s as simple as “Hello World”, that’s more than the guy still reading the entire book has built. A couple of my favorite platforms to play around with code on are codepen.io and repl.it. Quick to access and no setup required.
This technique is also great for motivation — take in those little wins and keep the learning ball rolling. Learning new things can be overwhelming. Keep yourself from breaking down by breaking the material down.
This may seem like it takes more time, but you will ultimately have a better understanding of the material and struggle less to put pieces together later.
#3: Learn by Doing
Why?
This goes hand in hand with #2. You need to practice and actually do it. If you can read a book, watch a tutorial, or listen to a lecture and recall concepts, that scores you some EXP. To level up, you need to actually apply that knowledge.
We’ve all experienced false competency in one form or another.
Scene: severely outdated, musty, wood-paneled college lecture hall.
Time: a very confusing one.
College-aged Sarah is internally collapsing over a calculus exam. She’s thinking, “But I watched the professor solve this problem multiple times!”
Yikes. It’s because she didn’t practice those problems and evaluate her true ability to understand and solve them.
How?
Build and burn
Build up an application/project/chunk of code, whatever. Celebrate your victory. Then destroy it.
Yes. Destroy it and do it all over again.
I wasn’t convinced of this technique at first, but it quickly became clear that it was a wonderful way to understand how components of your code work, discover new issues, and figure out how to troubleshoot them.
This is not the same as writing a sentence or a word over and over again to commit it to memory. Cloudy concepts become more clear with building the same thing repeatedly, slowly abandoning crutches like notes and Google until you have a more defined idea of what to use and when.
With that being said, looking up things is absolutely okay! I don’t know what kind of programmer I’d be if Google didn’t exist. But when you need to look up small things frequently, it can seriously slow you down and take up precious brainpower that can be spent on more difficult logic.
#4: Handwrite Your Code
Why?
Yes, I know. I said taking copious notes is not helpful when learning how to code, but this is different! This is where the idea of handwriting and improved learning outcomes works with coding.
This is writing what you would actually be typing into a code editor. Additionally, writing code will improve your whiteboarding skills for those technical interviews. It’s a very different experience from being parked behind a computer and can send you straight to “dead, blank stare” city if you are not prepared.
How?
Write it. Anywhere.
This is how I learned React. One of my instructors (shout out to Dina for pushing me to learn smarter, not harder) posted me up at a whiteboard and had me write out components for an entire to-do application in React.
To give you a visual, I put the file name at the top (List.js, App.js, Anxietey.js, you get the idea). Then I wrote out the entire component below, exactly how I would in a code editor.
Although this to-do app was nothing huge, it got the basics ingrained and I used that knowledge to build a more complex, full-stack project within a few weeks.
Again, I know this sounds like it takes a lot of time. It does require some effort, but this investment will save you so much time later when you are working on bigger projects, flying through your code, and not looking up every little thing.
#5: Explain Your Code
Why?
After writing it all out, my instructor had me explain to her exactly what each line of code did. It was painful and it was filled with a lot of long silences, but it helped me understand the small pieces.
When you understand the small parts, you will better understand how they work together in a complex project. With this ability, your skillset is inherently expanded and diversified.
Think of it this way: not only can you describe what legos are, you can craft Optimus Prime, Hogwarts, or the Millennium Falcon with them.
How?
Start at the beginning of your code and work down. Ask yourself “what”, “how”, and “why”.
For example…
- Why do we use a class component here instead of a functional component?
- What does this preventDefault() do?
- What will happen when this onClick() is triggered?
- How is data flowing through my application?
- What does X line of X function accomplish?
If these questions seem fairly straightforward compared to looking at a whole block of code… well, it’s because they are. That’s the point! Smaller parts are easier to work with. This will help you build and better understand the working whole.
#6: Refactor
Why?
Ask yourself, “Can I refactor?!”. Once you get something working, strive to make it more clear and succinct.
Looking for refactoring opportunities is important in building your optimization skills as well as improving developer empathy — lookin’ out for your fellow programmers and not making them sift through a bunch of spaghetti.
You want your code to read like a painting — it should tell a story. You can tell what is going on and what it does by looking at it. People are going to need to know what you’re talking about. They’re also probably going to appreciate if you don’t repeat yourself (DRY). Keep it simple, stupid (KISS).*
*If you think I am being an ass, I promise I’m not (not in this situation anyway). Please refer to this article. ❤
How?
I’m going to give you the same advice I got in college for writing papers… the advice I maybe forgot to take while panic-typing at three am.
Write it, let it simmer for a few days, and then come back to it.
Going back and looking at your code with fresh eyes will really make a difference — you’ll see things your fatigued self didn’t notice before. Trust me on this one. I recently looked back at an old project and all I could think was… “Um, excuse me?”
#7: Teach What You Learned to Someone Else
Why?
Learn one, do one, teach one.
This is the boss fight of learning.
You’ve learned the thing. You’ve done the thing. Now try and teach the thing. Being able to explain something will help you evaluate your proficiency and identify what you need to review.
Added bonus — any questions your star pupil asks are opportunities for you to improve further. You may be pushed to view your concept from an alternative perspective, take a whole new approach to teaching it, or explain something in a different way.
How?
Explain what you learned to someone else. Offer to do a presentation for your coworkers or class. Teach your family and friends something new. If you are able to do it and explain it well, that is one step closer to mastery for you and a helpful piece of knowledge for your audience. You are helping someone else while solidifying that knowledge within yourself.
If nobody is around, teach it to your dog or your cat, record a video of yourself, or explain it to yourself in the mirror. Might as well build up those public speaking skills too, right?
