June 5th, 2025

Are you 10X, or are others 0.1X?

I've worked with people of different technical ability over the years, but never really thought about it in terms of one person being X times better than the other person. Yet the term 10X developer is popular and thrown around a lot. In a recent off-site meeting where I met with leads from different teams, the topic of 10X developers came up, and I felt it warranted exploring my thoughts on the matter.

Junior vs Senior

A junior with a fresh university degree in computer science (or equivalent), joins a workplace filled with incumbents who have decades of experience, yet put out features at an apparently jarringly slow pace. The explanation from the seniors is that they meticulously think of all possible scenarios for each new feature, ensure everything is fully tested against all edge cases, and is properly documented and easily maintainable. The junior then starts to work and they submit one feature after another, not with the same robustness as the work product of their seniors, but in an acceptable state that meets client requirements. They put out 4 features in the time it takes the others to put out 1. Are they a 4X developer compared to the old guard? From the junior's perspective, who is working off what they learned academically, supplemented with what was self-taught, they had expected their pace to be the norm. So that means they would be 1X, and the old guard 0.25X.

Now what happens when a few months later it turns out there is a bug in the junior's code, or the feature the junior built needs to be expanded but doing so requires rewriting it from scratch, are they now retroactively not a 4X developer anymore? After all, they may have put out four times as many features as the senior developers, but now the team has to spend significant time to fix the bug or to ramp up the next project. Surely this unforeseen time affects the X ratio, but it's not easy to determine how much. How many months between them developing that feature and learning there are issues does it take for the X to be affected?

On the flip side, had the foresight of the senior developer, who knew to design their work in such a way that it is easy to iterate upon, fully mitigated the need for a rewrite? How does that impact their previous 0.25X rating? They can now bring out the next itertaion while the junior is spending double the time to rewrite the entire thing. To make it even more abstract, forget expanding the original feature - let's focus on the bug. The senior's code did not have the bug. In another world, no one ever finds out that the code the junior would have written would have led to a bug. So how would we even put an X on something we cannot quantify - is the senior developer still 0.25X here? No one knows about the bug. In fact, we can make it even more complex. Had the junior developer written the code, but despite there being a bug, no one ever found out or the powers that be decide that it will not be fixed. There is a bug in the code, but if nothing will be done about it, then how does it affect the X ratio?

Relativity

What I'm trying to get at is that the X is all a matter of perspective that is dependent on circumstance. We can expand the scenario above even more by having the junior be proficient at writing one type of feature, where the senior takes 4 times longer, meanwhile for a different type of feature the time taken is reversed. Now who is 4X, who is 1X, who is 0.25X? The notion of 1X and 4X being the same comparison as 1X and 0.25X is on its own a rebuttal to the existence of someone stating they are 10X, because the number is all relative to someone else. Being 10X requires another to be 1X. But then if a company hires only 10X engineers, does that not make all their engineers 1X?

Furthermore, the scenario above where one developer is less meticulous than another, and therefore puts out features more quickly than another, is a scenario that only works when the developer is allowed to do this. I would expect if both developers are on the same team, that their manager would have requirements for their work product. Each developed feature must meet agreed-upon requirements. Were these requirement made in such a way that the degree of documentation, quality assurance, and maintainability are up to the developer? I would hope not, but such workplaces definitely exist. Nevertheless, it means that the junior developer can only be 4X in such a work environment. Were they on a team where the code standards are rigidly adhered to, and now they are actually taking longer to develop the feature than the senior because they keep running into unforeseen edge cases while writing quality assurance tests, which they would have never even written in the less rigid work environment, then that means they are no longer 4X. On that team they would be less than 1X, maybe 0.5X, or from their perspective, seeing self as 1X, the senior would be 2X.

Conclusion

My point is that I don't like the term 10X, at least not without context. Recruiters will use this term to sell a company on the value of their clients, and it's understandable - most recruiters will not understand the nuance of when their client excels in one space and when they do not. And even if they did, there is simply no time to go into specifics like this when the company with open positions gets hundreds or thousands of applicants. For some hiring managers being told an applicant is a 10X developer might be enough to get them in for a round of interviews. But for me, it only raises questions. Rather than focusing on getting only 10X engineers, I'd rather focus on creating a work environment where everyone, relative to their earlier selves in prior teams, becomes 10X engineers.