Busting the 10x software engineer myth

This article is pure clickbait written to sell in this stupid Swarmia startup. :) 10x developers exist just like 10x musicians, 10x marathon runners, or 10x chess players exist. It may take a world-class musician a week to write a masterful symphony but it would take me way longer. Perhaps I'd never produce anything great so that musician would be infinitely better at it than me. Great chess players beat amateurs at least 99 times out of 100 so must also be 10x in comparison. Marathon runners run 42 km in like two hours but it would take me days to finish the same distance...

It's true for almost any human activity that there is a huge gap between the worst, the average, and the best. It is preposterous to believe that the same wouldn't hold true for software development.

I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy.

Some people like to be present and suck up.

But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too.

Some of the best engineers I know "visit" bits of code or infrastructure and afterwards it's a pleasure to use and rarely if ever has weird bugs, and if they do have bugs they're easy to root out.

What I'm trying to say is: high performers exist. But your organisation shouldn't be resting on the shoulders of those people.

People leave. If your 10x (or 3x or 5x) engineer quits: are you really going to hire 3,5 or 10 people to replace them? Unlikely. And even if you do, institutional knowledge is lost.

It's not a myth they exist, but you shouldn't depend on them.

> Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers.

The author seems to mean prima donna, not a 10x engineer and then goes on to destroy that strawman.

Actively sharing knowledge, mentoring etc... and code and architectural simplicity are a given for someone who's 10x productive. Most of the costs are in maintenance not the initial delivery and a 10xer's output would deliver over the life of the software use. Hard to decipher code doesn't sound like it would fit that bill.

I can cite many examples of a 10x engineer having an insight that greatly shortened the development time.

It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.

The original study (if I remember correctly) showed a 10x productivity difference between the most and least productive students on a given task. I find that very plausible. In real world settings the difference might be much larger, since some developers effectively have zero or negative productivity.

This article talks about a developer with consistently 10x productivity compared to the average developers in an organization. I think this is pretty rare. And I would consider it a warning signal. It means that either the average is really low or the hero is really a one-of-kind genius which will likely move on to a different job quickly (or get hit by a bus, per Murphys Law).

It could also indicate (as per the article) that the 10x developer is actually keeping the other developers down, e.g. by insufficient knowledge sharing or writing unmaintainable code. You often see this if the 10x developers is "the old guy" who develops at night and hates meetings of any kind. Removing this guy will cause an immediate hit, but over time increase the productivity of the remaining developers.

I see a variation on this article, several times a year.

I can't speak for other cultures, but the US has a fundamental mindset that all but worships "exceptionalism." We like mavericks, rule-benders, and exceptionally talented individuals. Being attractive, and having a winning [public] persona is also very helpful. Sometimes, good actors can use attractiveness and persona to cover up for a lack of accomplishment and substance, and often, people of great substance, are ignored, because they are not attractive, have "problematic" personalities, or are not particularly good at self-promotion.

I remember watching a documentary that compared the k-12 educational systems of the US, Germany and Japan. They looked at how high-performing students were treated, and how that affected their peers.

The US would concentrate on high performers, often to the detriment of their peers.

Japan would make high performers coach their peers.

They seemed to decide that Germany had the best approach. I don't remember exactly how that went (I remember extremes).

I'm a damn good engineer. Am I "10X"? I don't know, and don't care. I'm not in competition with anyone else. I get done what needs getting done, and I always have a ton of stuff I don't know, and still need to learn.

Another thing about the US culture (I was not raised in the US), is that it is highly competitive. We can't just be good at something; we need to be better than someone else.

That seems exhausting, to me.

I'm not competitive at all. I have worked on high-functioning teams, my entire career, and was never interested in competing with my teammates. The team competed against other teams, but that wasn't really anything that concerned me.

Anyone who doubts 10x devs exist either never met a real one or is merely protecting their ego. Software development is complex enough that I'd go so far as to say there's even 100x range even among those considered competent. We accept this range in sports and art, what's the hangup? It seems like someone who just learned deductive reasoning and feels like they could now understand the universe then someone says there are 10x'ers and they instinctively go Noooooo!

Sus are those who write to debunk it.

I work in ML engineering, and I’ve seen people work on a problem for the better part of a year with little to show for it. The non-progress gets on leadership’s radar, so even more resources get directed to crack what should be a solvable but non-trivial problem.

An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer. Not because they work 10x faster, but through better ideas and thought process, efficiency with their tools, and exercising leverage. This is even without considering their additional impact on the work of others.

I think this could be applicable in any software or tech field, as long as the best solution to a problem isn’t trivial or immediately obvious.

There are some good points in this article. At the same time, "10x engineers" are not a myth. Anecdotally, I have seen plenty of situations where the most skilled engineers in a group were many times more productive than the least skilled. If anything, "10x" greatly understates how big the difference can be.

There are two things here:

- What is a 10x programmer (what do they do better?)

- What is the impact of their presence (or absence) on a company

A 10x programmer is not someone who completes a narrowly defined task at 10x the speed of another engineer.

> In a controlled environment, the variation between most software engineers is much more modest.

Of course!

If you ask people to implement a small component as part of a large architecture that was already decided .. you won't find much of a difference in performance (unless you have people who are truly and utterly incompetent).

The excellent engineers would come up with a different design to begin with, but you can't measure that in a controlled study.

Now, knowing that 10x engineers exist, how can you use that to your advantage if you're a manager of a company?

If you yourself are not an excellent programmer, you can't just hire excellent programmers and hope they improve your business.

You will be fighting with them over control.

The key is to have excellent programmers in powerful position where they can call the shots about how to hire and manage and reward people.

If you are willing to give them that kind of power, then you have no business reading articles like this on the internet.

If you are not yourself an excellent engineer and are not willing to share power with excellent engineers, then no amount of reading of such articles on the internet will help you make the right decisions.

So… 10x engineers exist, but they don’t count because their productivity comes from superior knowledge or other factors? This is sort of silly. Just because you can ‘control for a factor’ doesn’t mean that said developer isn’t 10x more productive than everyone else. And providing one example of how this can go wrong says nothing about the general case.

I know an objectively measured 500x engineer.

In the '90s, Siemens AG and Ericsson made a joint venture called Ellemtel for a classic six-month death-march project: if it completed on time, the customer paid. Otherwise, discarded. Each company sent 250 engineers.

At the end of the six months, they delivered a working system. Fully half the code in it was by this one engineer.

Out of the 50 ish devs I've worked with closely, I've seen two I would say are in the '10x' camp. They were relentless in writing solid, simple, bug-free code, and doing so faster than everyone else. They were also effective in communicating their work. i.e. They weren't head-down in the corner savants.

Their productivity was also significantly more consistent across a range of areas and task complexity, compared with other devs who would slow if working in an unfamiliar area or on a more complex task.

Finally, good (and bad) decision making compounds with software. The right high level approach can pay easily pay of 10x over time just as a bad approach will result in buggy, bad performing software, and multiple rewrites.

In short, this article does not match my experience.

I churn this out every so often:

A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.

The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.

Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]

There's a twisted version of this "myth" that I encoutered: The demand for software developers grows much faster than the supply, so there is a temptation to hire wildly incompetent people, hoping that they still be able to deliver good enough product. As a result we have "1x" engineers, which are competent but rare, and "0.1x" code monkeys trying to get by.

Or to put it in a different way: "In the land of blind, the one-eyed is a king".

As I get older, and maybe because I worked at a company whose product is “talent optimization”, I think a lot of the “10x” thing is just a function engagement and passion. That is to say it’s not entirely skill or “intelligence”. You could take the best programmer but if you point them at a project they don’t give a crap about they’ll phone it in. Point them at something they’re passionate about and they’ll have absurd impact. They’ll think of more novel solutions, test and refine those solutions, and crank out the whole thing in record time.

If you want a 10x engineer, give them work they love.

There may be 10x engineers. But what I know for sure is, that there are engineers (or engineering teams) which make you perform at 1/10x of what you might have, by mis-carefully laying a minefield of:

* Build difficulties.

* Hidden dependencies.

* Multiple and conflicting sources of configuration information.

* Lack of documentation

* Incorrect/outdated/stone-cold lyin' documentation

* Mis-named executables, configuration files, variables, constants etc.

* Lots of global state

* Inconsistent and surprising design choices.

* Console noise inundation.

So, the supposed "10x engineer" simply knows a few paths through this mine, while the rest of you just keep triggering them with almost anything you do.

Anyone who has working in software for any length of time will have come across people who deliver orders of magnitude more high quality work than their peers: high output, high quality -- the 10xer. This post confuses that archetype with the similar-but-different high output, low quality archetype -- AKA the "cowboy", "hero", "prima donna".

It's a completely context-dependent assessment.

I was part of a team a few years back where I was certainly not a 10x dev. It was a team of... around 8-9 folks. 5-6 devs, PM, testers. There were jr/sr divides, but it was relatively smooth. My 20+ years of experience were helpful, but I wasn't 10x more productive than some of the lesser experienced folks on the team, and given the constraints and role I was in, there really wasn't a way to achieve that.

I've been on other projects where the experience level and other factors really exacerbate differences, and I've absolutely been "10x" in comparison to the others on the project.

The larger problems may come in with how you're treated, how you're viewed by management, etc.

"In a controlled environment, the variation between most software engineers is much more modest."

Well yes, but we don't usually work in controlled environments. With similar backgrounds/experiences, and strict project management controls in place, there's going to be far less variance possible.

This is a silly framing of the 10x engineer issue. That label originally designated someone who had written an unusual amount of excellent software.

Recently in the discussions here, people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero. This is not what 10x engineer means. Please find another label for that phenomenon, for example 10x faker.

Like some football players, some software engineers are a LOT better than others.

The measurement is value in $, which easily can be translated to 10x-1000x better.

I think this is a nice strawman. The difference between an engineer that writes truly good code and pushes the team forward, and one that is simply the only one left that understands their own mess should be obvious to anyone, except maybe the most stereotypically clueless manager.

"10x" is obviously a buzzword and not a literal measurement, but is there any real doubt that productivity differences exist? Or is is just fashionable to not admit this anymore?

I don't even consider myself a very good developer but I work hard, I have discipline and commitment, and I focus on getting the work done. This made me 10x engineer in most of the teams I worked.

And for a few years I had it well measured because I was working with the same app and I was estimating all the tasks for me and the others with high precision to my own performance. The manager understood that other team members wouldn't follow my pace since they were less familiar with the app, and it was OK for him to estimate 2x or 3x the time when planning. But at the end it showed that I was average 8x faster (and with better quality) which was not justified since they were also senior even they knew the app a bit less.

The worst part is that I was earning much less than them due to location... but at least I could justify a request for a 15% raise which was given with no hesitation.

The fact that this is constantly debated is sad. I've run numerous tests across various organisations. When measured it becomes evident that 10x is nothing strange.

Set some real world useful target. Give the task to individuals or small teams and let them go at it, with regular followup. Measure time, defects, maintainability, whatnot. Perhaps add some real world change of requirements mid stream? I've seen solutions ranging from hours to never.

What I see, and find very sad, is that most organisations have obstinately obtuse attitudes and handling of such simple analysis.

It doesn't matter if the variance stems from intelligence, creativity, work pattern, experience, clever tricks, tools, processes, etc, etc. If it's faster/better then find out why, and learn from it. Can it be taught to others? Change work processes? Hire differently? ???

Whatever works. But ffs: measure, analyse, learn, embrace.

I have a different take on 10x Engineers.

First, this is neither an exact science nor a multiplier (in this case, 10-times). I like to believe I have worked with a few of these "10x Engineers". I'm lucky to be technical enough not to be bullshitted by engineers and OK enough to sell to CTOs.

Here is my understanding.

They are not the ones who would produce XX times over a given period. It is not like normal/average engineers create X in 10 months; then they will do the same 10X in that same ten months or take 1-month to do it.

The pattern I see is that the work of these engineers lasts a very long time and stays relevant for quite a long time. Everyone who works with them is happy because they learn a lot from the actions or are predictable.

For instance, the QA team does not find apparent bugs or rare, most use cases, and the usual flow of actions and results happens.

I believe the 10X comes at a much later stage, over time, when the work is a rock-solid framework and foundation that everyone else can pick it up and work upon it.

I know I'm not very concrete, and I have to work harder to describe them in better ways. For now, it is more of a feeling I have after working with them. My only role was to understand them (not the technology) and shield them or cushion them from the BS-es that flow around anything that happens in a project/company.

We used to nod and agree on these lines -- So, what are our BS-es that we need to tell the management/client to cross this hurdle. But remember, we still need to make that BS happen.

Let me extrapolate the last part. So, I will huddle up the CxO of top Companies over a room, with concierge services waiting around to serve snacks, water, etc., but they won't be allowed to leave for a long time. Their phones are out of reach. When the other CxOs or executives are doing it, everyone else follows. I will throw around words like empathy; the design is subjective, iterative design, human framework, and all the jazz that pops up in my head. "The customer has to be able to find the shortest, simplest route to checkout."

Then I will meet up with the team, explain what I promised, and we will, kinda, laugh and wink. However, we will now convert those "Design is Subjective" to Objective Deliverable Goals and Binary answers -- YES or NO -- does this work or not - when that checkout happens, what steps, fallbacks, errors, and everything.

Companies eventually save a lot of money, as there aren't multiple iterations or griding other engineers 10-times.

> One of the most interesting recent studies comes to a very different conclusion. In a controlled environment, the variation between most software engineers is much more modest.

This is a silly comparison. The engineers I've worked with in my career that stand out don't stand out because they can write for-loops faster than others or public-class-Foo-public-static-void-main-string-args-System.out.println-hello faster than others. They are much more productive because they are better at ensuring they understand the problems they're trying to solve, and solving the problem with the least amount of superfluous work.

> No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts.

This example seems like a counter-example to me. It's important to separate out one's (potentially flawed) judgement vs the actual value an engineer brings. This engineer made everyone else less productive. Simply calling someone a "10x engineer" does not make it so.

> The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers.

The rest of the article is a distraction from this generally good piece of advice. For many things, finding a competent programmer familiar with your tools and stack who can write the CRUD operations you need should be acceptable. A lot of software engineering interviewing distracts from this, with gotcha trivia questions about whether one can recite from memory algorithms from a text book that are not relevant to the work.

The point of the article is not whether 10x factors have been observed, the point is that (in all cases the author has seen) they are dependent on circumstances/environment and not the individual.

Implicitly, he invites readers to re-evaluate their experiences.

To me, this rings true for most mundane organizations (not id software).

Doesn't really bust the myth, though does it? Just says that the 10x engineer is a sign that the company may be in trouble, depending too heavily in such engineers. From 25 years in electronic engineering, I guarantee that there are some engineers that are 5x or 10x others.

A fact I notice in a lot of teams and orgs, valid for both this and the 'heroes' discussion:

Every organisational silo has,in the long term, exactly one 10x engineer, a.k.a hero.

If there is no hero, the organisational silo will fail unless someone cares enough to take the role. If there is a hero, the need for a second one disappears. If a hero falls away, you'll have a few months of chaos after which a new hero appears.

People will naturally give problems and hard projects to the best available person, and generally people agree who that us. So one person with a slight edge gets all the training and quickly gets much better.

Heros are a consequence of organizational barriers.

Update: That last part is inexact. Heros are a consequence of knowledge barriers.

The article seems to argue that you shouldn't focus specifically on hiring 10x engineers, not that they don't exist at all.

Bad/clickbait title?

Some people seem really uncomfortable with the idea that individual performance can vary massively from person to person.

The article seems to make and fight a strawman argument, making a supposed 10x engineer a problem for information sharing, teamwork, etc.

In my experience, it is quite the opposite: while very few of the 10x engineer are indeed "leave me alone to solve hard problems; figure out yourself how to maintain my solutions within the enterprise", the majority makes simple, robust designs that are easier, not harder for the team to understand and maintain. And when they leave, they generally leave behind a system that is stable and does not need day-to-day meddling from a senior engineer, which gives enough time to find a replacement. My 2c.

It's not like there are 10x engineers, it's so many 0.1x ones that a 1x one is nowadays seen as something of a miracle.

If you have a team of decent developers then I think the article has a point. But imagine you're in a situation where 90% of the developers on your team are outsource contractors with below junior level of aptitude who have been up-marketed by talent agencies as "senior architects" and "technical leads." Now 10x makes a bit more sense.

Organizations with poor technical leadership fail to quality control hires and accumulate imposters. In this setting the lucky hire of a merely average developer creates the appearance of a 10x (or 100x) unicorn.

> In a controlled environment, the variation between most software engineers is much more modest.

I have a feeling the writing has never worked with 10x developers. You know, everyone knows, that there's a galactic difference between the average team member vs that 10x in the corner crafting code like an artist chiseling into a block of marble.

... and then there's that awe inspiring, humbling privilege when you score getting onto a team where everyone are 10x-er.

The variation between most software engineers isn't modest, it's a Mariana Trench of a difference.

10x software engineers are mostly 10x problem solvers who happen to be programmers. The driving attitude is refusing to work hard to accomplish something of low significance, which is mostly done thanks to: finding clever solutions, reducing feedback loops when debugging or testing, gaining proper understanding of systems to avoid empirical tweaking, asking around quickly when getting stuck, and also cleverly navigating company politics in order to ship something in environments where it is hard.

Ari-Pekka makes various plausible-sounding declarations, but he doesn't even try to make a case.

I know that I've had many colleagues that were next to useless - even, possibly, exhibiting negative utility. Let's just give that kind a zero. Then there are novices - smart people with little experience. They can get stuff done, but they need watching. Suppose we give those a 1. And suppose we give an "average" dev, fairly smart, with a lot of experience, a 2. Such a person doesn't need watching, and gets stuff done.

I'd say a zero needs to find more suitable work.

A 1 is worth investing in.

A 2 is most good professional devs.

So what's this x10 fellow? Well, I rate myself as a 2. I'm a journeyman, and I'll never be a master. But the people I've met that I'd rate as "masters" were no more than twice as productive as I was.

I can't imagine a dev that was 10x as productive as a journeyman. I've certainly never met one. Software development is a process of discovering and remedying bugs - from the requirements, through the design, to the implementation. These things take roughly the same amount of time, whether you are a journeyman or a "master". And once you have identified the problem, the solution is usually fairly obvious.

If this notion of a 10x dev is a real thing, then I suspect it arises in people who regard technology as some kind of woo. If you're recruiting a magician, then he'd better be better than any other magician, because you don't know magic.

I just wish employers would stop focusing on hiring 10x engineers, and instead focus on how to create an environment in which the overall standard can improve. What I mean is - you can take a superior engineer and put them in a crappy environment, and they will fail. Likewise, you can take an average engineer and surround them with support and they will produce a multiple of their raw talent. Focus on the things that make it possible to produce at a high level. For that matter, it strikes me that often those people that companies believe are producing at a high level, aren't. I saw this a lot in consulting - companies think Jimmy is just the bees knees, but in fact the reason he looks like a hero is that his junk is broken and he's constantly having to firefight to fix it. Often too, the loudest engineer in the room shouts down everyone else and "looks" like a leader when they are really the villain.

I saw for myself - there were places in my career where I was super productive, and places where I hardly produced anything. It had everything to do with the environment: politics, communication style, teammates, technology, and problem domain.

I am currently becoming so sick of WFH and boring to-dos that I am making the 10x software engineer myth true for all of you. You can thank me later.

This is a colossal strawman of an article, suggesting that a 10x engineer is someone who simply churns out features faster with a high degree of technical debt. It also talks about the "science of 10x engineers" being shoddy, and tends to regress to the mean under "controlled environments".

This entire discussion is deep in pointy-haired boss territory. First of all, creation and derivation of value from software is not "a controlled environment". Attempting to define things such that you can measure them means that whatever individual strengths and abilities people have will be washed out along with whatever advantages they could confer to the organization. As much as management wants to commodify programmers and treat it as an assembly line, programming remains a craft. It's not construction to a blueprint, but rather architect, engineer and builder all rolled into one—and the output is data and UI interactions with abstract purposes and mental models, not physical buildings with very straightforward goals and constraints.

The truth of the 10x engineer (or 100x or 1000x) is not that they code the same thing faster, it's that they find a better path. There are many different archetypes of this, you can't measure it, and you certainly can't hire for it, but with experience you can definitely see the impact of the smarter abstraction, the better anticipation of future requirements, the judicious application of YAGNI.

As an engineering manager the size of what you can accomplish is limited primarily by how you structure the team and give everyone the opportunity to play to their strengths. It's not about adding process and bureaucracy to ensure everyone feels equal, it's about setting up shared goals and fostering a sense of camaradarie so that natural leadership can emerge and everyone can do their best work.

Well, my experience is that to increase productivity the most important thing is not doing things. If you can filter out the meaningless features and shut down products that are a product of politics (giving someone a product to keep them happy even though everyone thinks it useless) you can increase productivity much more than focusing on the technical aspects of development.

Very sf-type of term, is it still in use? From an eu perspective the idea to rely on some members of your team to be 10 times more productive than others seems like a terrible idea for anything longer than a 1 month sprint. That's not to say people's raw smartness, competence and experiences are the same just that a better focus would be growing the team as a whole.

Whether or not "10x" exists depend on what "x" is. Some companies have very high hiring standards, so there the "1x" may be high enough that "10x" becomes really unlikely. But some companies hire almost anyone who can walk, and then "x"<=0, making 10x pretty achievable.

I even expect that some consulting firms to this on purpose, at least if they sell services to customers that are put off by paying according to the value generated by the best developers, they bundle the best developers with teams of low-paid underachievers, where the lead is 10x as productive as those, and where the total output still matches customer expectations. Instead of paying $1000/h for one person they pay $1500/h for a team of 10 people, even if that one person could have more or less done everything on his own.

If you haven't worked with one, you might believe it's a myth. Some folks, in the right place at the right time, are just better. Probably way more than 10x better, but dragged down by the same meetings overhead, at more than 10x the cost for no benefit, as everyone else. No I'm not one of them.

Pssh. As something of an outsider, its far worse than "10x." There's just a fundamental mismatch here, which I think is the elephant in the room. Where there are people like Linus Torvalds and Kovid Goyal, you just don't need that many software makers in the way we do it now, unlike the way you need at least X amount of construction workers or dentists.

Which, I believe, is not to say you can't have that many people working in IT, but a major shift of thinking is required. Software shouldn't be a product, and I'd go even further to say that it shouldn't even be a deeply centralized service. Rather, a lot of IT pros helping smaller individuals solve problems (and just happen to use software while doing it, in the way that e.g. astronomers happen to use math) would be best.

Why do you think Ari-Pekka believes it’s the organization of engineers that creates long-term sustainable productivity?

Hint: What does Ari-Pekka do for a living?

Most people want to believe that what they do is the unique secret sauce of value creation, and they want others to believe it too. This is basically what you call politics.

IMO the 10x engineer is not someone who is 10x more productive than their peers. It's the person who will identify and solve critical engineering design questions far in advance, such that if you took them out of the team, the team would be 10x less valuable.

A 10x Software Engineer is not somebody that can write programs 10 times faster. A 10x SE can solve problems that are 10x more complex. Because a 10x SE has a higher understanding and is able make design simplications and create better abstractions that allows her to not get lost on the complexity.

Case in point. I have similar years of experience as Linus Torvalds and feel I am pretty good SE, but I couldn't have written git. Because his understanding is in a different level. I am able to understand how git works, but he was able to come up with the concept. I was happily using subversion but he knew what needed to be different and how to implement it. It is just another level.

Assign a work of an enginner to 10 engineers and it will become a work of 10 engineers. My experience is "10x engineers" are ones who work alone in independent manner, removing all dependencies that can potentially pin down their progress.

"10x engineers" definitely do exist. Anyone who doesn't believe in 10x engineers just hasn't met one yet.

I've had the pleasure of working with two 10x engineers. One of them is a problem-solving and execution machine. I could understand what he did, and I think that I could have done the same, only taking 10x longer.

The other one... the other one isn't just a "faster me". His brain works on a qualitatively different way than mine. I probably couldn't have come up with the things he came up with, even with 10x or 100x more time.

These guys are also incredibly humble and nice, and hilariously funny. Fantastic humans all around. Stu, Matt, I miss you guys!

I have worked with 10x developers. And I have worked with -1x developers (stopping them from working made everybody else productive). Without the 10x developers things wouldn’t get done. Your demo/prototype wouldn’t be ready in time to secure the contract. Your production problems wouldn’t be solved fast. I suspect that certain (average) developers are jealous of the attention 10x developers (rightly) get. That’s understandable. But pretending that 10x developers doesn’t exist is silly. It’s like pretending that world class musicians/engineers/artists/… doesn’t exist.

There absolutely are different levels of talent between coders. But it is more nuanced than that - I rarely see anyone who is 10X better than everyone else at everything. But I do see someone who rocks one specific type of coding, while they are slow at others. Figuring out what skills you really need on your team, hiring the people who excel at those specific skills, and letting people spend most of their time in the area where they excel is how you get a high performing team. Also a pigeonholed team, though - there is balancing to be done in the long run.

The unit of software delivery agency is a team not an individual any more. That was in the days of Norton Disk Doctor where a single programmer held the whole problem in their head.

The question that is lost in the noise about 10x is “Does a team with a 10x programmer deliver software better faster cheaper than a team without one. More formally is a team with a power law distribution of talent more productive than a team with a normal distribution of talent.”

That is IMHO the question that really matters in terms of modern software delivery. Any thoughts on this question?

The solution proposed is not good because it presents “hire 10x” and “support 1x” as some sort of exclusive options.

Of course, the smart choice for orgs is to do both. If I had to choose a single (and I don’t) I’d go with a few 10x progs over dozens of 1x because small teams work better in general due to coordination overhead.

This is no excuse for letting 10x be jerks and I would probably run away from any hiring notice that talked about 10x. I think this follows my observation that smart people don’t talk about being smart, they be smart.

For a lot of basic crud software something is very wrong if there is even a possibility of having a 10x engineer. I worked on a project that was basically just forms. Should have been really basic, anything a junior engineer could build. Nope! The 10x engineer instead built out his own form library. Incredibly difficult to use, obviously undocumented, extremely buggy. To build static forms with a little bit of validation. So yeah he was a 10x engineer because he made everyone else a .1x engineer.

10x engineers most certainly exist, I've had the fortune of being able to work with a few and their true impact isn't in the code they themselves write but in the higher-level strategic/architectural decisions they make that impact the team as a whole. That being said it is also my experience that most self-described 10x engineers are anything but, so if one bases their impression of 10x engineers off those self-promoting cases then I can see how it would appear to be a myth

In many cases, I had to step into an Augean stable of code, i.e. a 10x dev had to deep dive into code produced by 10 1x dev. Coming out the other end, functionality went up by 50% with 40% less code.

Prior to being downsized at a multinational, I was asked to explain my database update scripts to a lady who had never seen SQL. Some of the queries took most of a page. That system slowly sank into the sunset. It's hard to do customer support when the database doesn't know about their new machines.

Well, if there are software companies that have 1.5x growth and there are that produce 10x and some produce 100x growth, then by definition developers in the 100x company are 10x more efficient than those in 10x company, assuming the factor a developer plays in company growth is significant.

It feels like these myths busters are a bit left leaning.

Sames as a topic about whether Tim Cook deserves his huge pay/bonus, to which the answer to the left leaning academic is, can you find a replacement for him?

Anyone trying to ”bust this myth” are to me suspect of either selling snake oil or just trying to defend their own mediocrity.

If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.

My biggest problem with 10x is that I see it applied prescriptively not descriptively. If it's just describing some fact about someone's output then fine. If you've got the data to backup your 10x trophy then good for you but I don't want to hear some shit about someone being a 10x developer because someone else said they were.

You also don't get to be a 10x developer by kneecapping everyone around you.

It's weird to focus on time to solve a problem when the software field is full of examples of challenges where you need a great engineer to be able to create a working solution at all, and an average engineer could never in their lifetime produce a workable solution. What's the multiplier factor on these?

Whether or not some people in a given field are 10x more knowledgeable or productive than others is a question that can be answered.

Whether trying to find 10x programmers is a good HR strategy is a separate question.

This article is just a stream of consciousness brain dump, which I guess proves that 1/10x clickbait authors exist.

Not sure about the exact number before the X, but remarkably capable people exist in every field of human endeavor including engineering.

I get the sense that some of this constant myth busting comes from HR people who want people to be interchangeable parts and don’t like it when they are not.

In my experience, 100x absolutely exists. It can be sustained in areas where someone has considerable amounts of closely-related experience; however, when innovating, it is only sustainable for up to a few months at a time and with great sacrifice in one’s personal life.

You cannot bust it because most of us have empirical evidence of a 10x engineer (whether it's 10x, 20x, or merely 3x doesn't matter -- there are engineers who can and hold projects all by themselves, with top-notch code and utmost speed and quality design).

> The company's CEO would walk into the space where the developers worked and loudly comment – even to outsiders – “sometimes it feels like X is the only developer who gets anything done.”

Their analysis: 10X developers are a myth.

Alternative explanation: 0.1X managers are a reality.

I’m not a huge fan of the 10X thing. I always feel like it panders to one’s vanity. I’m just a normal guy who enjoys what he gets to create.

But I’ve worked with a lot of people over the years who I thought of as 0.1X. They often just don’t seem to care.

I think 0.1x (or even negative x) software engineers are more common. The ones that introduce bad bugs, don’t accept feedback, don’t communicate well with PM and design, always want to refactor things… they can take a whole team down.

Well in the age of livestreams you don't have to guess you can just watch them work. To me pretty clearly Jon Gjengset Rust streams are what would I call 10X, although it all depends on what you consider 1x to be :)

I've never seen anyone be 10X better than, say, average consistently over a long period of time.

But I've been 10X better than apparently average a few times a few weeks at a time. Uh, part of the reason for a few weeks at a time is that as part of the 10X I got the work done very quickly!

My 10X cases were all when the planets happened to line up just right and, to use a baseball analogy, the work to be done was like a slow pitch right in my best strike zone.

(1) I was seeing a girl, and she was an intern and working for someone who wanted her to work on some old Fortran code. She couldn't figure out why the code was giving totally garbage results.

I glanced at her code and saw where she passed the constant 2 as an argument to a subroutine. So, sure, that can be dangerous. I glanced at the subroutine and, yup, it was changing the corresponding parameter so for the rest of the execution of the program the constant 2 had the value given it by the subroutine and was not 2.

She worked a day or two on this, and I solved it in about 180 seconds.

Why? I'd seen that in Fortran usage before.

(2) I was in a software house working as a programmer and fast Fourier transform expert at a US Navy lab. Some engineers at the lab needed an extensive software project done and set up a competitive bidding situation. For one of the engineers, part of the work to be done was some power spectral estimation of ocean wave noise, that is, quite low frequency. Due to some earlier experience at GE, I knew the basics of the Wiener-Khinchin theorem and also got the Blackman-Tukey book on the statistics of power spectral estimation, typed in some code to generate synthetic ocean waves and accumulate and display the power spectra estimates, then called the engineer and we met and reviewed my work.

The main point I had for him was that for the very low frequencies he was interested in, he could need dozens of hours of data and with much less data than that would be looking at small sample statistical fluctuations instead of good estimates of the actual power spectrum. Likely I got these results in 10X. Our software house got "sole source" on the work.

(3) I was at Georgetown University consulting in applied math and teaching computer science courses when a friend from college called. He flew up to Georgetown with several other people, and we met. Everything was inconclusive -- no one had any definite, good ideas. The problem was scheduling the fleet for FedEx. That was important because some Members of the BoD questioned if the fleet could be scheduled at all; crucial funding was being held up; the company was at risk of going out of business.

Finally in the meeting I just blurted out that I would solve the problem. Six weeks later I had the software running which was also the end of the semester for my teaching. I flew to Memphis, ran my program, pleased the BoD, pleased the founder F. Smith ("solved the most important problem facing FedEx"), and saved the company. I suspect that in time, that was a 10X effort.

(4) I was working on a Navy project to support both my wife and myself through our Ph.D. degrees when the Navy wanted an evaluation of the survivability of the US SSBN (ballistic missile submarines) under a scenario of global nuclear war limited to sea. They wanted the results in two weeks. That timing just fit -- my wife had a vacation planned for us at Shenandoah just after the two weeks.

From a WWII paper by Koopman's, I saw a continuous time, discrete state space Markov process subordinated to a Poisson progress and wrote and ran the software, Monte Carlo. The software was fast enough that I could generate and average 1000 sample paths quickly.

During a peer-review, an objection was that there was no way I could "fathom the enormous state space". In response I mentioned that after, say, five days, the number of SSBNs left was a random variable; it was bounded and thus had an expectation; the expectation was finite; the random variable had a finite variance; the law of large numbers applied; and averaging 500 sample paths would give quite accurate estimates.

I explained that intuitively Monte Carlo put the effort where the action was, and the reviewer, a well-known probabilist, responded "That's a good way to look at it." My work passed the review.

A second person, actually two people, had been assigned as an independent effort. At the end of the two weeks, they made no progress at all.

The Navy got their results on time, and my wife got her vacation on time.

(5) When I arrived at Georgetown, a prof had just completed a statistics package. One of the routines was polynomial fitting, but on testing the numerical accuracy was poor. The prof had programmed normal equations, and on that problem the normal equations are close to the notoriously ill-conditioned Hilbert matrix. I wrote a replacement routine using some orthogonal polynomial methods and got accurate results.

(6) I was in an AI (artificial intelligence), expert systems, project at IBM's Watson lab, and we were developing IBM's language YES/L1. We wanted rule subroutines. Our code design was to (A) return one call at a time from the whole stack of dynamic descendancy, (B) execute the RETE algorithm run-time code, (C) rebuild the stack of dynamic descendancy. I saw serious semantic problems with this approach and the coding was to take some weeks. I got some dinner, wrote and ran some illustrative code, in effect to call back into the stack of dynamic descendancy, at dawn wrote email to our team, got some sleep, returned at noon, and our programmer on the work was done later that day. I got an IBM award for the work.

There were a few more 10X examples.

I always put my pants on one leg at a time and have never walked on water in warm weather. None of these examples involved high stress. Instead the keys were context, e.g., I had everything I needed and background so that the work was in my strike zone.

I don't achieve 10X all the time. Heck, I don't achieve 1X all the time; e.g., in my startup recently I've been interrupted and slowed by some unpredictable exogenous obstacles. But now it appears that I've circumvented the obstacles and am making good progress again. Back to it.

Net: I don't think anyone can achieve 10X consistently over long time intervals. And I don't believe that very many people can just decide "next week I'll do 10X work." and be able actually to do it. Instead I suspect that most people can have 10X periods given the luck of the right circumstances.

In my experience, it's possible to identify these people early career, set up their environment to help them excel, and help them 10x. Actually hire a 10x off the street? Pretty damn hard

Denying that 10x <anything> exists is usually a shallow defense mechanism for our own egos. We aren't that good at <skill>, so we convince ourselves that no one else is either.

10x developers exist, but often they leave mess for others to clean up.

They cite a study that concluded “while programmers are better and/or faster than others, the importance and scale has been greatly exaggerated.”

Bah. Come on, OP. 10x engineers exist but much rarer than most think. Could you honestly see these people and NOT call them 10x engineer?

* Fabrice Bellard

* Linus Torvald

* Chris Sawyer of Transport Tycoon

* John Carmack

* Ken Thompson

* Jeff Dean

Software engineers that create negative value exist, so it shouldn’t be controversial that there are developers that go the other direction.

10x engineers surely exist IMO, but:

- There are 10x as many pretenders for every one real one. Management might mistake the fakers for the real ones because they are faking it on being charismatic. These engineers wreak havoc on teams.. everyone else is cleaning up their mess, the fake 10x gets all the credit due to the charisma and ego and too often the rest of the team isn't able to reveal the true situation. Management will often give these guys (never seen a fake 10xer who was a woman) huge accommodations and let them go off on massive projects outside of normal accountability and project management and when they come back a year later they've produced a big mess of garbage but a year was spent and the guy is charismatic so management has to have it in the product.

- Any given engineer might be 10x more productive in one organization than another. This can probably be indirectly correlated to the size of the organization

- Fake 10xers can drag down everyone else's productivity, and make themselves look better in the process.

- Real 10xer will produce an elegant architecture or solution that is easy to maintain and understand. The faker will produce a mountain of code with hidden bugs and put on an air as if no one else is smart enough to understand what they've produced.

- There's an element of "emperor's new clothes" with revealing a faker. Everyone knows they are a faker except management, and yet it feels impossible to stop pretending and pull the curtain back.

- Non-technical management makes it much easier for the faker to get their hooks into an org. Maybe the UI designer got elevated to VP of engineering and doesn't know much about code. Maybe a junior guy got promoted for being one of the first employees. These kinds of managers are juicy targets for fakers.

- Fakers often seem to introduce new tech to the stack so they can show it off on their resume, even if it doesn't fit the product well.

- Fakers make up clever names for everything they write as if they are marketing their code. Put stuff off in a separate library in a separate repo when it could have fit right in the main repo. Give it a clever name. Convince management to allow them to put it on github as open source so they can polish their external cred.

My last two positions the team was essentially sabotaged by a fake 10xer on each project. Reams of buggy code and huge management accolades, when the bad code starts to catch up to them them move on and leave tons of tech debt behind, and they move on to do the same thing at their next position. One of these guys spent 3 years writing a crazy library that used an alternate persistence strategy and when it got put in it destroyed performance to such an extent that when he moved on the whole thing was removed in a month or two and performance went up 100x just by changing everything back to a more standard persistence strategy. Meanwhile alternate persistence strategy went all over the guys's resume/LinkedIn.

Here we go again.

Those who believe in 10x software engineers are just dealing with 0.1x software engineers most of the time.

Why do we even discuss this type of clickbait posts, few times every year?

He's not even busting the myth.

He says 10xers exist, but they are bad for the company.

Who would you rather have, a single individual who's a "10x person".

Or another individual who can make all of your developers 5x more productive, because that individual created a framework/algorithm/model that is radically more productive than what existed before (e.g. think Jeff Dean at Google, DHH with Ruby on Rails, etc)?

just like every other domain, the problem is identifying the 10x dev

Is this just the IQ debate, or "nature vs nurture", on another playing field?

It seems very obviously that some people operate on another level than others. If methods exist to boost the "normal" people to the genius level, they have not found their way into the mainstream yet.

Surely you could bog them down so that they don't perform better than the rest. You could simply only have boring software issues to solve in your company. In that sense, maybe you could get rid of the 10 times developer.

Or you could hire only very good people. But looking at the sea of developers, it seems clear that some are better than others.

tl;dr

FILL YOUR EMPTY FUNGIBLE DEVELOPER SEATS WITH OUR FRESHLY TRAINED DEVELOPER CATTLE FROM SCHOOL OF PROGRAMMERS #36. CERTIFIED IN AGILE BEST PRACTICES AND ADVANCED JAVA BEANS. 2 YEAR SERVICE LIFE. PRODUCT OF DJIBOUTI.

A 9x mother will give birth a baby in 1 month.

Wow - an actual intelligent well thought out post on this very crazy subject. I agree with them ! And love the call out to psychological safety, an important and usually under- values area

Satoshi Nakamoto is a great example of a 1000x engineer (or a bunch of 1000x engineers) with an impact measured in trillions of USD, but the article may be right that he wouldn't have been able to have that impact inside a big financial organization, as his engineering is disruptive.