The Myth of 10X Developers
Legendary 10X developers: mythical creatures. Unicorns of the tech world, feeding on beer and pizza, writing thousands of lines of code per day.
In their early stages, startups work in a different way than mature organizations. Most startups not only build products by borrowing money, but they also take on technical debt. For them, delivering MVP quickly is essential, as early validation is required.
This environment gave rise to the notion of 10X developers. Like protagonists in action movies, these mythical developers can single-handedly beat up ten regular teammates in terms of productivity — or so the legend goes.
In real life, the so-called 10X developers are most likely cowboy coders — sitting alone in hoodies with their headphones on, working on a codebase only they understand. However, limited interactions and cooperation within teams only work as long as the codebase and the team itself remain very small.
While sometimes these teams can deliver more than those at more mature organizations within the same time frame, it is often done at the cost of quality. After all, there is no such thing as a free lunch.
Nowadays, when working with distributed architectures (micro-services, Lambda, cloud-managed services, etc.), there are thousands of possible solutions to every problem. DevOps and the cloud took away some of the burdens of managing physical servers. They also increased the complexity of software interactions (queues, APIs) and the required amount of planning.
Cooperation is imperative to create long-lasting and high-quality code. Having quick brainstorming sessions by the whiteboard before starting tasks could help teams save much needed time.
Yet, many developers still believe that they do their best work in isolation. I even dare to say that most developers will openly state that they are most productive when left alone, without unnecessary stand-ups, questions, or meetings.
But what is productivity?
According to Wikipedia:
Productivity traditionally refers to the ratio between the quantity of software produced and the cost spent on it.
While this definition might initially seem complete, it neglects to consider the quality of the software produced. Things get much more complicated once we add quality to the mix and start measuring other aspects such as maintenance time, bugs, time to onboard new developers, and how long the software can live without major refactors.
The truth is that the desired quality level can vary between organizations and heavily depends on their maturity level, team size, and use cases. In other words, we cannot arrive at a universal definition for either quality or productivity, as they are highly subjective.
For some very early startups producing this quirky, barely working, not very well designed MVP might work. Yet, the same wouldn’t work in an organization that needs to maintain a codebase for an unlimited period of time.
10X developers aren’t real!
This myth of hyper-productivity hurts many developers, especially for those who try to compare their long-term productivity with the one achieved in short periods of time (hackathons, all-nighters, etc.). Realistically, working day and night isn’t sustainable in the long run and could even lead to them feeling burnt out in no time. Working day and night isn’t sustainable in the long run and leads to quick burnout.
Instead of promoting crazy productivity, we should focus on promoting a healthy work-life balance. A career isn’t a sprint but a marathon.