The Truth in the Myth of a 10x Developer
A perspective on randomness in the software industry and on how to beat it
Every budding programmer would prefer being a star to being stuck at a dead-end job. But what is it that differentiates the best from the common? Can one be 10 times more productive than another? How do we even approach this question, given that programming combines individual contributions and teamwork, both being necessary? On the extremes, a communist worldview might lead one to believe that a 10x developer isn’t possible, while the individualist views, combined with a reductionist view of programming (we can reuse code, right? …right?) may lead one to believe that most large corporations’ engineering teams are overstaffed by a factor of 10. The truth is, of course, more complicated. Here I’ll try to summarize the state of affairs as I understand them and highlight some of the things that you can use to propel yourself to a better, more successful career.
The brutal truth of the Pareto principle
The Pareto principle (roughly 80% of consequences come from 20% of causes) is simply a fact of nature. It is true in the creative industry, as well as in engineering, both of which meet in software development. Rarely a majority of companies/projects/experiments succeed in a given niche. Most never leave the drawing boards, few survive for a long time and even fewer have a lasting impact on society and civilization. Yet most of us chase the dream of being an impactful person, whether we express this in terms of impact, money, fun, awesomeness, power or anything else. Whether we like it or not, there will be circumstances outside our control that will define who we are and how important our output is.
In this environment it may be psychologically very damaging to set a goal of being a 10x developer. It may be so bad that it may drive us into depression. That’s why it’s important to understand what we are up against and not to expect a spectacular success even if we follow all the rules of self-improvement. If we get a slightly higher-paying job after improving our skills, we should celebrate and not worry about perfection.
But still, somehow there seems to be a class of people that seem to always be at the right place and the right time, and always do just the right thing to propel their companies to success. Just to give some examples:
- John Backus — Known as the pioneer of programming language theory and the inventor of Fortran. Look at what he invented and the awards he got.
- Edsger Dijkstra — Another pioneer of programming. Look at whom he influenced and the number of publications he’s written.
- James Gosling — This guy not only invented the most widely used programming language in existence but also has written more than 10 books while continuing to do impactful work.
- William Gates — You might have heard of this guy from Seattle, who once has jokingly admitted to having no more marketable skills than MS Office proficiency.
Clearly there exist at least some 10x developers. Meanwhile, the number of software devs in the world is counted in millions. Alphabet (Google’s parent company) alone hired more than 50000 extra people last year, most of whom won’t end up on Wikipedia. Can we somehow cheat our way through the Pareto principle, so that we have even a chance in this world, rather than committing all the mistakes everyone else commits and being doomed to mediocrity from the get go?
The features of a 10x developer
I’ve compiled this list based on my own experiences and research. As I continue to grow as a developer, I will add to it, (but probably in another article). I currently firmly believe in every one of those points. Feel free to disagree or add to it in the comments.
1. Understanding that programming is gambling one’s time
They understand that software development is like gambling in the sense that 99% of the code may be rewritten or just thrown away.
The thing a person gambles in programming is their time.
Because of this, they approach development as a search problem, planning the things they need to find out, then doing the minimum work required to find them out, and only then writing the production code. When writing the production code, they also approach it the economic way, adjusting the exact amount of testing, optimization etc. to the requirements of the specific module they are writing. A corollary of this is that they have their own development plan rather than only relying on their manager’s plan or an issue list on Jira, github etc.
2. Being a lifelong learner
They are lifelong learners, always trying to learn about new tools and techniques, at all needed levels of abstraction, from micro optimizations (if needed in their niche), through languages, to architectural patterns, as well as domain knowledge.
3. Being an expert user of one’s tools
They are expert users of their tools, from the algorithmics of their field of programming, through general algorithmics, up to their programming language, IDE, testing frameworks, libraries, CI/CD tools and so on.
4. Recognizing when one cannot contribute due to mismanagement
More simply, when they don’t like their efficiency at a job, they go to another where they can contribute more.
5. Seizing opportunities
On the more positive side, they seize opportunities for contributing in impactful projects and jobs. As I explained before this may be conscious about the impact or not. For example they may say they “like” an opportunity better, where “like” means they have an exceptional taste for better approaches to problem solving and for more successful organizations.
6. Being agile in order to handle requirements
They understand that requirements will change, they do everything they can to find the real ones out and they understand that the agile development process is the way to develop software in such conditions.
7. Self-awarenes and applying the psychology of programming
They apply it, even if they can’t name the emotions. There are multiple things that can slow people down, such as feeling attached to code (discourages a rewrite), being attached to coworkers (discourages job changes), feeling overwhelmed by accumulation of small failures (promotes procrastination) etc, that they can get over relatively quickly, compared to other people. They aren’t simply aware of those human shortcomings, they have specific processes to work around them, such as their own TODO list, task switching, having friends outside work etc.. On the more positive side, they know the feeling of flow and try to do tasks that trigger that feeling, to get them to produce more without having to have other people motivate them.
8. Logging one’s work
They log their work. This may take many shapes and forms, such as long commit messages, comments in the code, merge request descriptions, a folder with separate notes for each task or a journal. What’s important is that they can find out later why they did something and not something else. They can explain their work and answer questions about it 6 months or even years from the moment they wrote the code. And more importantly, they can continue and/or publish their older work.
Why you won’t have your own Wikipedia page
The problem with reading this article, and reading short form articles in general, is their transient nature. We don’t normally read these to change our life, we read in order to feel something. We feel educated, enlightened and that makes us happy. The whole industry of journalism is taking advantage of this fact that we don’t need the written word to actually have an impact on our lives (while having an impact still, but this is another topic). This ties into one golden nugget that I heard in a podcast while learning to trade the financial markets. Most people are collectors of information while, to succeed in the markets, you need to be an applier of information.
Most people are merely collectors of information
You need not only to learn a rule, but to journal your trades, ruthlessly account for all occasions where you didn’t apply the rule and devise a more specific process to help you follow the rule in the future. I firmly believe that something like this is true in programming as well. This, the passive approach to learning, is why I think most people will be stuck at a suboptimal career. Whether it’s this advice about being a 10x developer or a book chapter about Java design patterns, they won’t apply what they read or they won’t apply it correctly.
Conclusion
There are things to do to improve our chance. In fact I believe that every developer can find something to improve in their approach to problem solving and to programming in general.
Be the applier of information.
Take one of the points from the list, reflect on your past and future work and obsess over it. Use other sources, find a book about it and do everything in your power to incorporate it in your process.
