A couple of months ago, developers on Twitter started spamming jokes or frustrations about the mythical “10X engineer” in response to this tweet by a startup investor from India. Thankfully, outside of this guy’s original tweet thread, nobody else was buying the “10X engineer” nonsense. Unfortunately, the fact that this guy tweeted it in the first place means there’s too many people out there laboring under a delusion that desperately need to be set straight.
Before anyone starts making the perfectly reasonable argument that there was no way this guy could be serious, I looked through the original thread and his Twitter feed – he seems to be serious. Given that his list basically reads like a list of bad developer stereotypes, it’s clear that there are several people out there who don’t know what good engineers look like within an organization. For the record, I’m not claiming to be the type of super engineer this guy thinks he’s tweeting about, but as someone who’s worked with great engineers at various jobs over the years, the things they have in common bear no resemblance to this “you might be 10X engineer” list. So here’s the truth about “10X engineers,” before you hire the type of developer that ruins your company.
Real “10X Engineers”
First of all, if you’re gong to assign a number to highly effective engineers, it’d be a lot closer to 2X, which is a lot more believable than someone being 10 times as productive as an average engineer. Calculating this is tricky, but measuring engineering output is tricky. Lines of code written is a terrible metric – generally speaking better engineers are more concise than others. Time taken to close a ticket is tough because not all tickets require comparable effort (although some people may like to pretend otherwise). The truth is, trying to measure and compare engineers is largely subjective and it’s incredibly hard to limit things to just what the engineer can control. That’s a large part of what makes the “-X engineer” conversation so full of crap – it’s not like we’re comparing 100-yard dash racers where you can get a simple, objective measure of quality. Even so, a basic understand of how multiples work should give you your first indication that anyone talking about “10X engineers” has no idea what they’re talking about.
Another thing to remember about highly productive engineers is that the higher productivity generally manifests itself less as increased individual output and more as time saved across the team over the long term. Things tend to work a little better, get through QA a little quicker, and users stumble upon fewer issues once deployed. In the end all these little improvements add up, you just don’t notice the individual improvements at the time, but the aggregate effects on the team are very visible.
By the way, if you’re looking for these types of long-term time savings, it’s quite easy to develop them in-house with your existing developers. It’s all driven by experience. Specifically, experience with the code base, experience with the development history of that code base (the decisions made and why they were made at the time), and experience within your company’s industry. Experience with the codebase lets developers identify the causes of bugs quicker (or even if it’s a bug), and just get work done faster. In my experience when a developer is significantly more productive than others, it’s because that developer has a lot more times spent in the code in question. If there’s something that gives 1 developer a productivity edge over another developer with experience in a codebase, it’s likely because while both developers are experienced, the faster one probably has a better grasp on the history of the code. That faster developer doesn’t just know the code, but also why the code was written the way it was, as well as the lessons learned along the way. It’s not as big a multiplier as experience with the code, but it’s additional context that makes developers more productive. The last thing that makes some developers more productive is knowledge of the industry they’re working in. That gives developers a better understanding of then problems users are trying to solve, and helps them make better design decisions upfront.
Another sign of hyper-productive engineers is that they tend to focus on tools, automation, and processes to increase overall productivity. Contrary to stereotypes, productive engineers aren’t blindly opposed to process. They understand that good processes safeguard against bugs and careless errors. Productive engineers understand that building an infrastructure that ensure quality speeds up everything. That means they’re willing to take the time to write unit and integration tests, do code reviews, go through QA, etc.
The biggest benefit to having developers like this in your organization isn’t just the code they write, but also the mentoring they offer junior developers. The best developers make everyone around them better. The best career advice I ever got was “Don’t ever be the only one who knows how to do something.” Good developers take that to heart, which means bringing everyone up to their level. They share experience and knowledge, they offer opportunities for other developers to work in the same codebase they work in. They know making the whole team better is the best way to increase productivity on an application.
It’s sad to see there’s still people using the term “10X engineer” with a straight face, and the signs that someone is a “10X engineer” from the original tweet thread reads like a list of bad cowboy coder traits. Developers that actually are significantly more productive have a focus on the long term, care about the infrastructure and process that are designed to protect code quality, and believe in making everyone better. That’s the type of developer you should be holding on to if you can find them.