One of the things I've been struggling with lately is how to go from being a senior or somewhat experienced engineer[1] to being an exceptional engineer[1:1].
To be clear, I'm not talking about reaching a level of global fame (i.e. on the same level as Linus Torvalds, Guido van Rossum, Rich Hickey, or whoever else you idolize). What I am referring to, more generally, is how to get to a place in which one is recognized as having extraordinary skill.
I started thinking about this more recently in response to a passage in a book I've been reading:
With some tasks, we stop short of our highest level of proficiency on purpose. The calculus we perform in our heads suggests that the added effort it’ll take to find and learn something new will probably yield a diminishing marginal return, so we stop learning. For instance, we learn how to make use of a word processor or Web server by mastering the most common moves, but we never learn many of the additional features that would dramatically improve our ability.
When this same pattern of arresting our development is applied over an entire career, it yields fairly unsatisfactory results. For example, most professionals progress until they reach an “acceptable” level, and then they plateau. Software engineers, for instance, usually stop progressing somewhere around five years after entering the workforce. Beyond this level of mediocrity, further improvements are not correlated to years of work in the field.[1:2] [1:3]
I was eventually able to track the source of this statistic to the research of [Dr. K. Anders Ericsson](Dr. K. Anders Ericsson), but in trying to locate it I ran into another interesting finding: that the correlation between IQ and performance in a domain decreases over time, and that after more than five years of professional experience the correlation ceases to be reliable.[1:4]
Put together, the two suggest the following: continuing to do what you've done in the past will eventually fail to net any further improvement. Similarly, intellect alone will only help you get so far. For reasons that are as likely to be co-incidence as anything else, both intellect and what I think of as the brute force approach to skill acquisition both cease to be meaningful contributors to one's growth at around the same point in time.
I like to call everything after this point the "endgame".
I'm not using the term in the chess sense of the word, in which there are relatively few pieces left on the board. Rather, I'm using the term in the massively-multiplayer online gaming sense of word, referring to a class of gameplay only available to characters who have otherwise completed the game's level progression.
The endgame's unprecedented difficulty is accompanied by structural differences from what has preceded it. It introduces new modes of (self-contained) progression, in which advancement requires spending time in a very different manner from what brought you to the endgame in the first place. The endgame is typically impossible to reasonably approach until you are prepared for it.[1:5]
For many people, the endgame is where the true meat of the game lies - it's a place in which simply logging time is necessary but no longer sufficient. Actual progression within the endgame requires both skill and deliberate focus on an entirely new set of activities.
In the real world, most people seem to level off when they encounter the skill endgame. They're either unwilling to invest further, satisfied with their level of expertise, or they're unable to adapt their methods of practice and learning in a way that will enable them to grow further.
It's hard to know what the exact breakdown of motivations is. For most people, I would hazard a guess that the individual in question is presenting themselves with a false choice: "work harder, or keep the status quo". Presented with such a choice (and, often, competing interests for time - at this point in their career the person in question may well have started a family), they make what seems to them to be a rational decision and choose to invest their efforts elsewhere.
For those that don't fall victim to the false choice, some number will want to advance but won't know how (either because the information is unavailable, or the resources are). Eventually, demoralized, they'll likely switch to a different focus area within the field - or perhaps transition to a different field entirely - in order to continue experiencing intellectual growth.
Some final number will have both the motivation and a clear idea of what would be necessary to progress, but will find themselves blocked by the structure of the institution they're operating in. This tends to happen in less flexible corporate cultures, or in cases where the individual has wound up on the losing side of a larger political battle.[1:6]
Measuring Skill
Part of the reason so many people plateau may be that it is simply not clear at what point one has entered the endgame. There are multiple reasons for this, but the most important is the difficulty in getting a clear indicator of one's own skill. Skill estimation is a notoriously hard problem to solve, as a considerable body of research has shown.
Assuming such a thing as one's "true" skill exists, the associated challenges entailed in measuring it (let alone decomposing it into constituent parts) are non-trivial. For starters, individual traits may play a very different role in one's overall skill, depending on the nature of the skill itself. To what degree does intellect play a part? Emotional intelligence? Experience? Environment? Economic incentive? How different do the answers to these questions look when we talk about the skills of an athlete vs. a software engineer?
To begin, we should dispatch with the notion of a single linear skill tree - even the term "tree" is misleading, or only relevant insofar as the roots of the tree are just as vital as its branches. When thinking of skill, it is important to be considerate of tracking progression in many directions at once. Part of the difficulty in thinking about skill lies in how diverse talents can coerce into measures like speed or effectiveness.
I'm not anything close to an expert in this area. An exhaustive review of the literature here would be well beyond the scope of this post (as well as my knowledge). Skill measurement is widely understood to be an objectively hard problem.
That having been said, there are certain heuristics that can be helpful. When you're first starting out with a new skill, you know next to nothing, and so learning almost anything makes you better. For a diverse skill arena like software engineering, there are many different parts of the ladder you can begin climbing, any of which will have a material effect on your overall skill. Over time, you begin to acquire enough of a common lexicon (due to shared patterns across specializations) that you're able to reason about the difficulty of issues in a different focus area from your own.
It's not too long after this point that measuring your skill in relation to others becomes more complicated. This tends to happen most in the early-to-middle ground of most people's careers; a point at which they've acquired some specialized knowledge, and a fair amount of generalized knowledge, but not enough context to understand the depth of other people's experience in their own specializations.
This balkanization into specializations is a particularly hard problem, and one I don't have any prescriptions for. My focus here is not on how to compare skills across specializations but rather to focus on narrow depth; I am not trying to tackle the problem of comparing a database expert to a compiler expert.[1:7]
My experience with attempting to understand my position on a skill tree has been that it becomes easy to see and define the nodes behind you, but only possible to grok one or two nodes beyond you. Nodes greater than one or two away tend to fall into one of two categories: they either seem unapproachable, or seem to be not so different from nodes you already understand.[1:8]
This sort of relative heuristic offers us little by way of absolute identity, but turns out to have extremely practical implications as far as choosing habits that enable us to continue to grow.
Growth Habits
In thinking about how to reason about growth habits in the endgame, a good place to start is on habits that are equally valuable in the endgame as outside of it. With this in mind, the best advice I have come across is to find someone who is just slightly further along than you are and to ask them for help.[1:9]
It's important that any mentors not be too many nodes away from you, otherwise they won't know or be able to remember how to approach the problems you're facing with the appropriate context. Conversely, it's only so helpful to ask the advice and help of people currently at your level - they're trying to figure out the same things you are!
If most people plateau at a certain point, however, then by definition the further you go up the ladder the fewer people there will be above you who can help you. Further complicating things is the reality that people well into the endgame may have significantly different specializations from yours. This is where being in a well-networked community (e.g., Silicon Valley) or a large company (Facebook, Google, Microsoft, etc.) can help you. Most populations are normally distributed, so if you want to find someone in the tail, your likelihood of finding them increases as the size of the population goes up.
Of course, people who are well into the endgame typically do not possess enough time to help all of the people who approach them for help. They are likely to be asked for help and advice by many people, a good number of whom will be considerably below them on the skill ladder. You can only imagine how many emails Linus Torvalds gets from college students.
This means that not only are there very few people at the higher rungs of the ladder, but they're also overburdened by requests for help. Getting around this is itself a hard problem, and begs the question of what obligation experts have to share their knowledge as opposed to deepening it.
I don't have a generalizable system for identifying people with only one or two rungs above you and approaching them for help. I wish I did, because then I would spend less time thinking about this and more time trying to learn from them.
If you can't get time with people who are at the right skill level, the next best thing you can do is to read things they have written.
Blogs are probably good when it comes to people high on the skill ladder - if they're at the right point in their career they won't be spending that much time writing, and the things they publish will be fairly high quality. If they're publishing something on their blog more than once a week, they're probably more focused on writing than they are on the skill you're trying to learn from them.
Books are better than blogs, for three reasons. First, the format of a book allows for considerably more depth of engagement. There are more things in heaven and earth than can be covered in a blog post, and while a book has its own limitations, it gives more time to examine a subject more seriously.
The second advantage of books is in their mode of engagement. Reading a book forces you to disengage from other distractions to focus more fully on it. Studies indicate that not only are we all generally terrible at "multi-tasking", but that the path to true mastery of a subject demands full attention for regular, brief intervals.
The final advantage of books is that we have an established social mechanism by which we can assign and estimate the value of their content - the book review. While you can try to judge the value of a blog post by its comments, it's not quite the same as having (sometimes long-form) reviews to read to contextualize the quality and content of a book.
There are other decent forms of written media as well. Depending on the nature of the skill, there may be guild publications you can subscribe to. Journal articles can be an exceptional source of new insights and depth, though their specialization of focus can make discovery and accessibility a problem.
If you're lucky, you can find curated lists of the best articles and papers for your domain area (for instance, this page has the Best Paper awards for Computer Science in various focus areas going back to 1996). This sort of resource is invaluable, and also enables you to see what depth looks like in closely-related specializations to your own.
The final thing you can do is to deliberately take on projects that you know to be hard. Hardness here is contextual - what you regard as hard may not be hard for others, and similarly there are tasks you once regarded as hard that may no longer be so.
Growth under this strategy requires you to attempt something you consider a considerable stretch of your known capabilities. This is a different sort of brute force approach to skill acquisition; it isn't the same as continuing to do the same things you've done in the past is, but it is still a naive approach and much more likely to result in failure.
The danger here is that you may not be able to learn from your failures without some sort of guidance, which is why this approach in isolation is likely to be less valuable. When paired with a good mentor or other supporting resources, however, taking on extremely difficult projects can have a multiplicative effect on your rate of growth.
One key benefit to taking on the right project is that the outcome can lead to feelings of accomplishment and satisfaction - even in the failure case! By contrast, mentorship and education don't always trigger the same reward centers, which can make them less motivating.
Deliberate Practice
The quote that inspired this article comes from a book that counsels that deliberate practice is what enables you to keep growing when others stagnate. Deliberate practice is the research focus of Dr. K. Anders Ericsson and has been covered somewhat extensively in U.S. media. Deliberate practice is defined as having the following components:
- Requires full attention for brief intervals
- Provides immediate feedback against a clear standard
- Breaks mastery into small goals
- Prepares for setbacks and builds in resilience
The biggest takeaway from the research into deliberate practice is the insight that neither more time nor more effort are necessary (though you do need to be able to commit to dedicated periods of focus). To reduce it to its most trite and banal: "work smarter, not harder!". If you're logging tons of time trying to improve and you're not noticing a change, you're probably doing something wrong.
Extreme skill - or at least, extreme skill as it currently exists on a normal distribution - should be within the grasp of almost anybody. If this sounds unlikely, there's actually a fair amount of historical evidence that suggests that we as a civilization have become much better at deliberate practice over time, shifting the entire curve to the right. For instance, in Ericsson's book Peak, he talks about this in the context of music:
In the early 1930s Alfred Cortot was one of the best-known classical musicians in the world, and his recordings of Chopin’s ‘24 Études’ were considered the definitive interpretation. Today teachers offer those same performances — sloppy and marred by missed notes — as an example of how not to play Chopin, with critics complaining about Cortot’s careless technique, and any professional pianist is expected to be able to perform the études with far greater technical skill and élan than Cortot. Indeed, Anthony Tommasini, the music critic at the New York Times, once commented that musical ability has increased so much since Cortot’s time that Cortot would probably not be admitted to Juilliard now.
Of course, it's easy to take that as a feel-good soundbite and go about one's day, but much harder to actively push the edges of the curve right yourself. For instance, how does one take the abstract requirements of deliberate practice and turn those into concrete activities for a skill such as software engineering?
Some of the things covered in this post clearly fit the requirements. Others, e.g. mentorship, do not. Some of the requirements themselves are hard to apply to technical work. For instance, what does it mean to break software mastery into small goals? What clear standards exist to measure oneself against?
I've been thinking about the skill endgame in one form or another for quite some time, and in a near-obsessive manner for the past few months. Sitting down and starting to write about this has led to a lot of thoughts coalescing (it has also, unsurprisingly, unearthed much more consensus than I had anticipated). Something to be said there for deliberate focus, after all.
At this point, for all of my musing, the one thing I'm left wondering is what else I'm missing. Not the obvious things - absent skills or missing practices - but the unknown unknowns, to quote Donald Rumsfeld; the structural insights about the nature of improvement that haven't surfaced yet.
If you've also been thinking about this for a while and feel that you're in a good position to provide guidance on the skill endgame, I'd love to hear your thoughts. Whether you're an expert yourself, a veteran in the industry, or someone coming from a completely different background - let's get a conversation going. I'd love to know what I'm missing.
~ V
Discuss this post on Hacker News or on Twitter (@venantius).
Footnotes