Few Tricks, Not Everything
A common refrain in programming circles is that you should study compilers. The argument, advanced by people like Steve Yegge, is that once you understand them, you'll recognize compiler problems everywhere and can apply proper computer science instead of hacky workarounds. That's true, but it's not a unique selling point for compilers. You could say the same for queuing theory, computer architecture, mathematical optimization, or operations research.
A natural rebuttal is that you should study everything. That approach is getting harder, though, as the collective body of knowledge grows in both breadth and depth. More importantly, telling everyone they should be a broad generalist ignores that this is a matter of taste. For some, a better strategy is to take the advice Gian Carlo Rota described: learn a few tricks.
A long time ago an older and well known number theorist made some disparaging remarks about Paul Erdos' work. You admire contributions to mathematics as much as I do, and I felt annoyed when the older mathematician flatly and definitively stated that all of Erdos' work could be reduced to a few tricks which Erdos repeatedly relied on in his proofs. What the number theorist did not realize is that other mathematicians, even the very best, also rely on a few tricks which they use over and over. Take Hilbert. The second volume of Hilbert's collected papers contains Hilbert's papers in invariant theory. I have made a point of reading some of these papers with care. It is sad to note that some of Hilbert's beautiful results have been completely forgotten. But on reading the proofs of Hilbert's striking and deep theorems in invariant theory, it was surprising to verify that Hilbert's proofs relied on the same few tricks. Even Hilbert had only a few tricks!
This pattern shows up in many fields. An analysis of world-class judo players found that most rely on a small handful of throws, concluding:
Judo is a game of specialization. You have to use the skills that work best for you. You have to stick to what works and practice your skills until they become automatic responses.
In fiction, characters often improve by acquiring more techniques because that's easy to depict. In reality, deepening the techniques you already know is frequently more effective than amassing a portfolio of hundreds of "moves." Joy Ebertz makes a related point about amplifying strengths instead of endlessly fixing weaknesses:
One piece of advice I got at some point was to amplify my strengths. All of us have strengths and weaknesses and we spend a lot of time talking about ‘areas of improvement.’ It can be easy to feel like the best way to advance is to eliminate all of those. However, it can require a lot of work and energy to barely move the needle if it’s truly an area we’re weak in. Obviously, you still want to make sure you don’t have any truly bad areas, but assuming you’ve gotten that, instead focus on amplifying your strengths. How can you turn something you’re good at into your superpower?
Why Specialization Works
This approach is effective in games and sports because you can maneuver into positions that leverage your strengths. It works even better at work, where there is no opponent trying to expose your weaknesses. A rival colleague isn't going to force you onto a project that requires skills you lack. If you study queuing theory, no one will steer you away from projects where it's useful.
Your key skill doesn't have to be a formal field of study. For years, the main skill I've been cultivating is something like "looking at data." It's not what most people would call statistics; I rarely need anything as sophisticated as logistic regression. It's not what we hire data scientists to do, either—at least, not the ones we screen for.
I'm not going to tell you to take this approach, but I will note that being specialized rather than well-rounded has worked for me in several disparate fields, and it appears to work for many others.
Choosing the Right Skills
The most common question that follows is: what skills should you learn? The honest answer is unsatisfying: pick skills where you have a relative aptitude (compared to your other options) and a good environment to learn them. Generic advice like "learn X" is usually worthless because it fails to account for individual differences. When people say "Forth is very productive," they probably mean "Forth makes me productive," and they haven't considered how well that generalizes to people with different aptitudes or contexts.
Early in my career, I followed this generic internet advice and learned Haskell, Lisp, and Forth. I even co-implemented what might still be the highest performance Forth processor in existence, a 2GHz IPC-oriented processor, and programmed it. Despite that effort, I found Forth to be at best 1x on productivity—not the 100x tool some claimed. Overall, that kind of advice was very low ROI.
Two skills that clicked for me personally are "having an adversarial mindset" and "looking at data." When a company I worked for was beta testing a custom bug tracker, I filed some of the first bugs on it, putting unusual things into fields to see if it would break. Some people were baffled; the authors, however, appreciated it. This didn't feel like work—it was something I had to stop myself from doing. For a decade, getting better at testing and verification felt natural.
The Importance of Environment
Finding suitable skills is half the battle. The other half is deliberately putting yourself in an environment conducive to learning them. This sounds obvious, but almost nobody does it. People who say they want to learn infrastructure often don't ask to work on an infra team or join a company with a dysfunctional infra org. I've seen interns join product teams because they didn't know they could request something else, then transfer away after their manager discovered their preference.
Even Steve Yegge noticed that the most common question from college candidates is about training and mentoring, indicating how much people value learning opportunities. Yet, in my experience, people rarely make decisions that optimize for what they claim they want.
For me, my first job at Centaur was a great place to develop an adversarial mindset for testing and verification. The team accomplished work comparable to peer projects at other companies with much larger teams. I doubt I could have learned as quickly on my own from books or the internet. People who are world-class have too many bits of information in their heads to compress into a book or blog post. In sports, coaches convey this over time; for programming, the best alternative is to find a team full of experts.
On "looking at data," my own improvement was gradual when working in environments where data wasn't taken seriously. In my current environment, surrounded by people like Rebecca Isaacs who are great at understanding data's limitations and informing analysis with deep domain knowledge, my progress per year has exceeded the entire decade before.
One caveat: this environment is inherently local. My current employer might be the least data-driven of the large tech companies I've worked for, but my specific vicinity is a great place to learn that skill.
On Long-Term Strategies
Most career advice is outcome-oriented, telling you to have a long-term goal and walk directly toward it. The argument is that a random walk moves you only sqrt(n), while a directed walk moves you n. This isn't wrong, but it underestimates how hard it is to find an area suited to you. I found mine by trial and error. Some of my acquaintances have picked a direction without knowing if it suits them, only to discover years later that they hate it or are bad at it. Wandering randomly and ending up sqrt(n) down a path you're happy with seems better than walking n down a path you're unhappy with.
A related observation: excellent management is a surprisingly accurate predictor of finding a team with a high density of world-class experts. Excellent managers have high retention and a long queue of people wanting to work for them. In contrast, seeking out the most interesting-sounding or hardest problems tends to attract so many people that it creates dysfunctional environments that persist indefinitely.
More common is to think of skills in terms of discrete fields like "compilers" or "queuing theory." It can be more useful to think in terms of cross-cutting skills like "looking at data" or "having an adversarial mindset," which can be applied across many areas. There are many interlocking aspects to this that a single piece can't cover: how to balance working at different skill levels, from high-level like "looking at data" down to "Bayesian multilevel models" or "typing speed," and how to pick skills that are likely to be applicable. Some choices are obviously bad — basketball or boxing won't get you far if your goal is to have an impact on the world or make good money. Between plausible alternatives like computer architecture and PL, though, trial and error among semi-reasonable options is probably fine, provided you're willing to experiment quickly.
