The judicious selection of what to learn next
The Universe is a big place. For someone who’s keen on learning new things and absorbing information, that is both a blessing and a curse. On the one hand, it’s great because it means there are many different things you could learn next. But then you encounter choice paralysis: with so many options, which one should you choose?
Even if you consider just professional knowledge, there’s still a huge collection of paths you could tread. Should you know more about object-oriented programming, or should you learn about functional programming? Or both? Is it time to level up your Objective-C knowledge, or should you diversify and have a go at learning Python?
Here’s how I decide what I should learn next.
Know where you came from
You can start to make sense of the options by evaluating your current level of skill. This is not straightforward—the oft-quoted Dunning-Kruger effect shows that it’s hard for novices and experts alike to objectively rate their level of skill. What you don’t know is, if you like, an unknown unknown. But it’s possible to remove that uncertainty.
Review your recent work
Take a look back at the work you were doing on your most recent project, or couple of projects. What went well? What didn’t go so well? Is there something that took longer than you expected, or was a lot harder than you thought it was going to be? Once you’ve found out where you had problems, you can start to identify what you need to know in order to keep those problems from recurring. If you get into the discipline of reflecting on your work frequently, then it need not take too long. I spend about 10 minutes at the end of each day writing a journal entry that lists:
- What I did on this day
- How it went
- What this shows I should learn
You could find a chart of the skills relevant to your work, and compare your abilities to those listed. I regularly check my programming ability against the Programmer Competency Matrix (and even created my own version to address things that were missing from the original). The rules for these charts are simple. For each row, look at the skills described in the first column. If you know everything described at that level, move on to the next level in the second column. As soon as you find something you don’t know about or can’t do, stop: that’s your skill level for that row.
Ask someone else
These matrices can help you with the task of reflection, but they’re no substitute for asking people who’ve seen your work for honest, constructive feedback. This could mean asking your boss or your team-mates. If you’re a senior developer, you’ll definitely want to ask the junior programmers: maybe there’s a thing you learned to do years ago that they’ve got a newer—and better—take on. Even if you’re in a one-person company, there are still people you can talk to about your work and your skills: your clients, your contractors and your peers at your local developer group will all be able to help you.
Know where you’re going
When you’re equipped with some idea of what your current skill set is, ways to improve those skills or adopt new ones become clearer. But which path should you follow? It’s not enough to know what you can do now; you also need to have an idea of what you want to do in the future.
What’s the project you’re currently working on all about? What about the thing you’ll be doing next? Are there things you could learn to make that easier? This is a good set of questions to have in mind whenever you start some new work. Perhaps you know that your next project involves a lot of 3D graphics but you need to brush up your OpenGL skills, or you’re going to add a Facebook feature to your app and don’t really know about their API. The targets you uncover by asking these questions will be short-term learning goals: they’ll help you work on the thing you’re doing right now. Regardless of their importance, understanding them could be pretty urgent.
Where are you going? I don’t mean that if you’re reading this blog post on the train, then what’s your destination—I mean, what’s your plan for your career? Do you intend to be an in-depth expert in some specific technology, or more of a generalist? Do you want to become a more senior programmer, or do you want to concentrate on other relevant skills like business analysis or leading your team? Answers to these questions give you the important (though not necessarily urgent) things to learn about.
By knowing what your goals are, you can look at where you are and make a plan for how to get where you want to be. If you’re striving to take on a particular role, you can look at a job description for someone hiring for that position, and find a list of skills that are important to have. My friend Scotty from iDeveloper once gave me some good advice for thinking about this: try to write a paragraph outlining how you wish to be seen by other people in your community. Take that paragraph and decide what you need to change in order to make it a reality. This can tell you about new things you need to learn, or about things you’re currently doing that are no longer relevant to your strategy.
Our Chief Learning Officer, Aaron Hillegass, wrote one of the best statements about learning:
Before going any further, assure yourself that you are not stupid and that some things are just hard.
There are lots of things in the world that you do not know. This is not because you are stupid, but because there’s so much out there to learn. The first step on the path to improvement is the judicious selection of what to learn next.