People will keep becoming software engineers. Some will be fresh computer science grads. Some, looking for new challenges or higher pay, will come from other industries.
All will come to learn that you can never stop learning. One day it’ll be how a new area of your company’s codebase works. Another day it’ll be a new library or framework your team just adopted.
The question of “How do I learn a new X,” where X is one of these things, has many answers. “Build something with X” is the most common one I see. It’s not a bad one, but what unites engineers if not a knack for optimizing?
Before I became a software engineer I studied learning. I took courses on it, read books and papers on it, and made it happen as a day job. The other day I found myself using that knowledge for the millionth time to get familiar with a new library for a job interview.
I definitely gave myself hands-on experience with it, but not by “building something” in any meaningful way. It struck me that the principles behind what I did do are ones that others getting into the field (or already in it) might want to know.
Four themes that jump out of the literature on learning are:
As I describe each one you’ll start to see how “building something” can be a perfectly good way to involve it. You’ll also see how the underlying ideas could be (and have been) used in much more targeted and bite-sized ways, or how you could direct your building in ways that make much more learning happen.
I put this first for a reason; this is the big one. Retrieval also called “active recall” or “generation” in the literature, has a specific meaning here, i.e. the opposite of “recognition.” The more you dredge up the material from scratch instead of passively picking it out from a list or looking it up again, the better you remember it.
It also makes you more capable of using it in a new situation where it’s unclear exactly what the right thing to do is, which is big for engineers. Two especially effective ways of doing retrieval practice are self-testing and “elaboration,” or verbally explaining something to yourself or someone else.
The idea of “interleaving” is huge in the learning literature, referring to mixing up the order of the material you’re learning. For example, instead of learning about concepts A, B, and C in consecutive blocks of study time (AAABBBCCC), it’s best to learn about them in alternating ones (ABCABCABC) or shuffled ones (ABCBACACB).
Another effective tool is studying examples of something being used, a common feature of software guides and docs. This shows you how a concept works in new contexts, and remember from the last section how recall helps you know what to do in open-ended situations? This is similar. By learning about something not in an isolated way but in a way where it’s surrounded by different environments, your brain creates more diverse associations with it, getting a better grasp of how it works and how it’s used.
I put these two together because they’re fairly simple but they’re no less crucial for the learning process. To learn new concepts, you have to expose yourself to them repeatedly. You also have to sleep. There’s no getting around it. These are biological necessities; sleep consolidates memory.
The effectiveness of spacing out the multiple sessions it takes to learn something has its own name, the spacing effect, and was actually one of the first things discovered in the field of learning science, by Herman Ebbinghaus in the late 19th century. The desirable difficulty is the name of the game; the more you can strain your brain to remember something, reaching back in time for it, but still end up remembering it, the more it sticks.
Duolingo is one organization that illustrates really well how to use all four of these. They have exercises that involve retrieving correct words from scratch, they pepper old vocabulary into new lessons, and want you back on the app daily (and aren’t afraid to tell you).
“Building something,” and especially with new app frameworks (which by nature touch all parts of building an app) can be a truly great way of learning, and can involve all four Rs. You repeatedly, often over the course of days, have to retrieve from your memory the best way of doing a certain thing, and often in different contexts. Just keep the following things in mind.
Projects done in the wild inevitably make you use certain tools much more or less than others. If you want to really learn something, you also have to understand its edge cases, which can cost you time, or its niche tools, which can save you time. So be structured about it. Focus on one section of what you’re learning after another. Interleave the pieces if you can. Don’t try to learn all the parts at once. Duolingo, you’ll notice, doesn’t just throw the whole language at you; they pick specific sets of new vocabulary to introduce in each lesson, eventually giving you full coverage.
Don’t look back at the documentation too frequently. Do retrieval practice. Give yourself small, targeted challenges. When learning a new library, for example, you can take a handful of methods and say: what’s something I could do with these pieces? And then find a way to do it. Then take a different chunk of them, and do the same thing. Do this over time, giving yourself some solid nights of sleep between learning sessions. (I only gave myself one with the new date formatting library, but even that can be enough sometimes.)
As much fun as it can be, and as much as it can pad your GitHub, you don’t need a whole project to learn something new in software. Get your hands dirty with it in a variety of contexts, get some sleep in between, and you’ll be golden.
Also published here.