Learning to Learn

I landed a new job recently at a pretty great company after spending a little time out of work to relax and recover from years of on-call and high-pressure situations. The experience so far has reminded me how important it is that I figured out a learning methodology for myself many years ago during high-school, and I thought it might be useful to discuss my process so that others can pilfer insights.

Context is important, especially for learning something new and discussing how to learn it, so the environment is this: I have to learn about a fairly large video game SDK that companies can use to rapidly create games on top of Unity. All kinds of generic game entities, data serialization, user interface layouts, and accompanying architectural structure like IoC containers and memory-efficient event dispatching are included in this SDK. It’s a laundry list that can be rather intimidating to approach.

The first thing I do is approach the thing to learn in a top-down manner, so that I can relate concepts from a game to the high-level ideas within the SDK. I like this approach because it allows me to incrementally improve my knowledge about the thing to learn. Details and expertise aren’t relevant at this point, but working on this solid understanding of concepts is critical to understanding the vocabulary of the problem.

Once I feel that I have a solid grasp of enough concepts I move on to a categorization phase where I attempt to isolate the core pieces of functionality from other parts. These core components are things that are used everywhere and represent ideas that I will need to be familiar with to get anything done. Other categorizations are fine to do at this stage as well, and in the case of the video game SDK, I have made several categories like “remote data loading” and “game content management”. I focus heavily on these core components and dig into the details, which in programming is code, but for other areas, like math, could be researching trigonometric identities, or for a novel it could be research into a time period. This is the most important phase because you are focusing on building up the kernel of your knowledge of the thing.

The other topics you’ve categorized can be covered in a similar manner, but you will need to determine learning order. Ordering these topics is rather difficult because you don’t truly know the thing you’re studying yet, so the challenge is to recognize when you’ve made the wrong selection and pivot to a different topic. For the game SDK, I could have started with the generic game entities, but those rely on a host of other features to work which would send me on many tangents. Instead I chose to start on the “remote data loading” topic, which lead me incrementally to many other higher-level topics, and eventually to those entities. It’s important to pick a single thing as you traverse the topics from your starting point because it gives you the ability to track your learning against something concrete. For me, I used the “boost” concept, which applies beneficial buffs to the player, from the game entities to track remote data loading to entity creation and saved data serialization.

Each time you iterate from your starting point to something concrete you will find yourself noticing overlapping knowledge and you will gain speed. An important point is that you do not have to remember everything from your deep dives, because you will be doing many dives that will repeatedly cover topics. Repetition and incremental absorption of information will let you ramp up very quickly.

Most importantly, you need to figure out what works for you. I am capable of sitting down and reading through dry documentation and code for hours without getting bored, but you may need something more interactive, which for code could be setting breakpoints and stepping through using a debugger. Once you find a methodology that works, you can practice and refine it, but you’ll only be successful if you enjoy it, so make sure it’s for you.