I’ve had a few¹ people ask me how I seem to learn technologies so quickly when I’m always complaining that kids are a temporal black hole that suck in all available free time and mental capacity. It was an interesting question! It challenged me to actually stop and think about whether I do anything specific when learning about new things. I realized that I did. Apparently I do have a personal methodology.
The approach I outline below is what works for me, personally. Perhaps it will work for you as well. There’s no harm in trying, right?
At least a little time. Not much, but a little. Say 20–30 minutes, 2–3 days a week².
Some weeks I struggle to even find that much time to set aside! It can be hard. Especially with kids. Or if, you know, you want to have a life outside of work. But there are always ways. Ultimately it comes down to prioritization. If you really need or want to learn something, this is really probably the bare minimum time investment.
We’ve just established that there is no free lunch. I lied. Actually no, I didn’t. I may have implied there was a solution to learning when you have no time, but there isn’t. You do need a little bit of time. Just a little. But it does change the question we need to ask ourselves to, “How to invest the minimum time possible to get the maximum return in knowledge?
Different people have different learning preferences. Visual, aural, verbal, physical and so forth. I am a verbal learner — so the methodology I shall soon present is geared towards verbal learning and may not work for you. Given that, it’s doubly important to first discuss what our learning goals are.
With only a small amount of time up your sleeve your primary goal should not be to learn a new tech in-depth. You won’t have time to become a master or an expert. ‘10,000 hours of practice’ may be a vast oversimplification, if not an outright myth, but an hour a week, broken across a few days, won’t take you far.
So: Your primary goal should be to translate ‘unknown unknowns’ into ‘known unknowns’.
A metaphor that helps me is to think of someone dumping a 1000 piece jigsaw puzzle on your desk. There’s no box. You don’t know what the picture is. If you were asked, “Tell me what that’s a picture of”, you would likely handle the task in a very different way compared to if you were just asked to ‘assemble the puzzle’.
If your goal is just to assemble the puzzle you don’t even need to know what the picture is. You might find the corners, then find the edges, group them by shade or color, brute-force edge pieces until they fit, group the inside pieces by shade or color, and so-forth. At some point you’ll figure out what the picture is, but it may take you a while to get to that point.
On the other hand, if you’re just asked, “what is it?”, there’s no need to waste time assembling the puzzle. Just flip all the pieces face up, look for bits that seem related, try to find things that seem familiar.
Translated back into the technical domain, focus on ‘what’ over ‘how’. You can learn the ‘how’ on an as-needed basis. For example, if you know ‘Technology X’ has ‘Feature Y’, and ‘Feature Y’ is useful in ‘situation foo’ — when you hit ‘situation foo’ in your work then you can work backwards from there.
What if there are no books and the documentation is poor? Tricky! Personally, if I have any choice in the matter, I’d probably not choose a technology that wasn’t moderately well documented. If you don’t have any choice follow the general tips. Look for as much similarity as you can between what you’re trying to learn and precursor tech, then look for ways to understand how it differs.
Now it’s time to apply what you’ve learnt!
But you won’t know how, because you were skipping code samples and only skimming documentation.
The trick is — if this technique is going to work for you — by now you have a mental map of how the technology is supposed to work, what it can do for you, and what special or unique features it has to differentiate it from what you’re currently doing. So although you don’t initially know to directly apply what you’ve learnt, you’re pretty sure you remember a section of the documentation that talked about ‘Feature X’ which would be really useful right now.
Now, then, is the time go back and read the relevant detailed documentation or code samples.
That’s pretty much it! Read as much as you can, as quickly as you can. Focus on the class of problems the tech is meant to solve and key features and differentiators. This technique works really well for me, I have successfully applied it to learning frameworks like Spring, Play, Ktor; languages like Kotlin, Scala, Haskell, Elixir; middle-ware like RabbitMQ and Kafka; and other miscellaneous tools like Puppet, Hashicorp Consul and similar.
I hope these tips work for you, too — and if you’re happy to leave feedback, I’m always interested in hearing about your techniques for fast learning.
 Specifically, two
 In my case, this is a function of the length of my commute and the a probability of getting a seat.
 Paper tech books are expensive, in Australia at least, but if you are happy with electronic copies those are often very much cheaper. But really what you want to do is convince your workplace to provide you with a subscription as part of a training budget.
Create your free account to unlock your custom reading experience.