In programming circles, there’s a certain kind of discussion that rolls around every once in a while about “the myth of the 10x engineer.” The premise is that there are programmers out there who are worth 10 other programmers. People debate whether this is true, and argue that, even if they do exist, they’re almost certainly so difficult to work with, you’d never want them on your team.
I’m writing this to say that the arguments against this premise are simply cope. People often get distracted with thinking that 10x means literally writing 10 times the lines of code as someone else. If you ask me, people making that logical fallacy are revealing themselves to be 0.1x engineers. It’s not about LOC; it’s about outcomes; getting the result you’re looking for 10 times faster and with 1/10th the problems. And, (not) sorry to burst such bubbles, but 10x software engineers exist in exactly the same way that 10x people exist in every human endeavor. And, sure, some of them are jerks, most of them are normal, and some of them are great, again, just like in every other field.
The analogy I like to use is professional sports. Take football for instance. There are 32 teams in the NFL. Every year, the sports press is talking about 2 or 3 teams, led by some quarterback or running back or receiver who is head-and-shoulders above the rest of the league. Here’s a group of people who are already in the top 0.1% of all people who play the game to just get into the NFL, and hold a minimum salary position. But then you have people who are so much better than that tiny group of people that they are paid 10’s of millions of dollars a year because they make that much of a difference. Do they throw 10x as many passes? No. Do they run 10x faster? No. Do they make 10x as many touchdowns? No. Their stats are not literally 10x someone else’s. But their effect on the outcome of the game is 10x that of other people’s. And some of them are jerks about it, and some are not.
Now for the anecdata.
About 10 years ago, I hired into a Fortune 250. After getting my laptop, and getting everything setup, my manager gave me a simple task of updating some software that he had written awhile back. I not only made the change he wanted, but I also published an installer, setup a one-page web site on a departmental server to distribute it, and sent out links to the updated app, along with some other applications that my manager had also written.
That took me a day.
Turns out those changes that I made in one morning, and published in the afternoon, had eluded a previous hire for eight months. He simply couldn’t get it done. And no one in the group liked him, to boot.
Once we got going, I was tasked with rewriting an application my manager had written several years prior, which was now creaking under the strain of expanded use. It took him a couple months of white boarding for me to understand the business process and get the model correct, while I played with a couple of different tech stacks, and different architectures. After a few months of getting the database schema and the workflow sorted out, I started coding in earnest. Within a year, I had a beta version, and people within our own group started using it to shake out the bugs. After another six months or so, things settled down, and we started rolling it out to the rest of the user community.
My program was fast, it did what engineers needed it to do, and nothing else, and despite being lousy at design work, it also looked nice, if I do say so myself. People were happy to use it. It helped them get their work done more quickly and more easily.
The second week on the job, I went to a meeting that included another group who normally did these kinds of applications. They had been promising my manager that they would write this program for 10 years before I ever got there, but never had. (This is why my manager had written his aging version to begin with, and why he had hired me to rewrite it.) One of the managers of that group in that meeting said to me — over his shoulder, without even looking at me — that he was going to kill the project I had just signed on for.
I decided I didn’t need to go to those meetings.
After seeing that I had written a working program, and people were starting to use it — and even like it! — this other group hired a new project manager and staffed ten “off-shore resources” to start writing their own version of the same program. It took them three years to reach beta. Their program performed so badly that they hired Microsoft consultants to try to help them find ways to speed it up. They failed. No one liked their program. It didn’t follow the business process. Their program even included a social media component at one point! As a result of all these shortcomings, people were refusing to use it, in favor of sticking with mine.
As you can imagine, this situation caused this other group no small amount of embarrassment. The manager of this other group eventually leveraged his political power to get my boss’ boss replaced with someone he had brought into the company, who immediately told my boss to stop working on the project. After a couple months, we made a patch to fix an urgent bug without permission, and my boss’ new boss used this as an excuse to force us to hand over our program to the other group, put my boss put on a PIP, and relocate me to a different group. It was such a cluster that the CIO eventually called the managers into a meeting to figure out what the heck had happened, and the offending manager was moved to a different department.
To summarize: it took me a year and a half, working almost entirely by myself, to write a program that a couple thousand people were using and liked. Compare this to another other group which took 10 people 3 years to write a crappy version that no one would touch. If you do the math, that makes me a 20x engineer, without even considering the intangibles.
I have other examples.
After I was shuffled off to a new group, I found that they were using an archaic program to do a core function. It was terribly slow, and needed users to post-process the results in Excel to get what they needed. I decided I could improve it. The current version had been written over 3 years by a whole team of consultants. It took me 3 months to write a program to replace it, which worked much faster, and gave people only the info they needed, without the need to post-process the results. Once I started getting close to being done, I was finding that the entire function that the program was providing could be replaced with a much simpler version! It was going to save a ton of time! But then my “manager” killed the program by convincing another group that they should take up the idea and integrate it into our PLM application, when we all knew full well they would never do it. But, again, I had written a better version of an application at a factor of something like 20x.
I had other similar experiences at another Fortune 250.
I had written a program to track free licenses and historical usage for all our engineering department’s seats of various CAD and FEA software. I wrote it in PHP. It was blazingly fast. Like, blink-and-you’ll-miss-it fast. People liked it. I didn’t know it at the time, but another group had been writing the exact same idea at another location. They used the early .NET stack. There were really 2 ways of accomplishing this task, and they chose the other way. It was much slower, and had gaps in the information. Naturally, people liked my program better. I had written the program in a quarter of the time it took two people to write theirs. That’s a factor of 16x right there. They even admitted mine was better in every way. But, in a similar fit of pique as my previous story, my boss at the time forced me to retire my version, against the users’ wishes. (I got clearance to bring the very new — and now unused — server home, where it served me faithfully for years, and I ultimately considered it a win.)
After 3 years of wasting my time, this same sociopathic manager eventually gave me a job to do that my coworker had done many times before. I believe he meant to humiliate me by giving me a task he didn’t think I could do. Within a few days, I had modified the scripts my coworker had written previously to do the same thing in 1/3rd the time, and my results were almost completely correct on the first try in staging. My manager was aghast and called me on the phone to express his absolute incredulity. I don’t know why. I guess he thought I hired someone else to do it or something? I eventually explained that I had been coding since 8-bit computers, and it taught me to always, always consider the run-time considerations of what I was writing. I don’t believe he was satisfied with my answer. The truth — which I wouldn’t explain to him — was that the original scripts had database connections nested in large loops. Refactoring the logic was easy to spot and do, and that was a large part of the speedup. It was such a simple programming oversight that I didn’t want to throw my coworker (who I respected) under the bus over it.
So, yes, 10x engineers exist, and I believe my history gives me the right to claim to be one of them. My problem is that 0.1x, petty, manipulative, ambitious managers also exist, and several have taken out their frustration against me over the course of my career by purposefully spiking my projects so that they could hire more people to do the same jobs, and therefore increase their “power” in the company by way of justifying more budget.