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 ]

I think too much faith is put in the abilities of most management; otherwise this Ask-HN article might not have been asked.

Probable examples of 10x, Steve Wozniak for Apple, John Carmack back in the day, Dennis Ritchie, Tim Berners-Lee, Jeff Dean.

If you aren't getting 10X output, it's possible that the problem or situation you have placed the person limits them to less than 10X.

I do agree that there are far more people who claim to be 10X than that there actually are and that many come with costs.

Also it is simplistic to claim a person is 10x. A more accurate measure is seeing a 10x effect. Writing key software that saves a company or gets a company bought is a 10x effect. I've seen that happen several times.

Otherwise, I am a thoroughly mediocre performer. I'm a minimum effort Loser[1] all the way.

[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

I think the -1x programmer is even more common, the ones that have negative productivity and actually create more work for other programmers. I've encountered many of these types over the years.

They are usually the very hard working type too. The kind who when encountering a problem always solves it by piling on more code, never refactoring, never taking a step back and thinking about the problem. You don't want to be seen idling at your desk, better keep typing.

I've had days where I've ended up doing literally nothing, but still objectively outperform some colleagues because they rammed some shitty unstable undocumented race-condition hack into the codebase.

In my experience, the '10x' programmer is not necessarily more productive (as in amount of work done in a certain timeframe), it's that the 10x programmer does better work, resulting in time savings down the line. Fewer bugs, a more flexible architecture, etc. It can be the difference between being able to easily add a new feature in version 2 and having to rewrite half the application.

The other points you make might be big problems depending on the situation, but this? What's wrong with someone taking a day off after a burst of productivity? This seems like classic valuing of face-time over results.

The "10x" works 16 hours a day for 3 days and produces a chunk of code that works, does what it's supposed to, ahead of schedule. So far, so awesome.

But the rest of the team is working away on the rest of the project. Suddenly they're lumped with a huge chunk of code that they don't understand. They weren't involved in the design decisions, they didn't pair-program or brainstorm any of the code. It's pretty impenetrable. And the "10x" who wrote it is now unavailable after that "heroic" sprint so they can't even ask questions.

Teams work together. Heroic sprints of productivity followed by absence is not working together. It's leaving other people to clean up your mess while you claim the credit.

Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time.

Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..

1) A very small amount of code

2) Isolated from everything else

3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious)

Most people would kill for a colleague who wrote code like that.

No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins.

Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.

I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.

This is a well known major impediment for creative persons in any field. You can explain things after they are done, not while you are doing them.

This is why average developers create such a drag on productivity. They always want meetings, explanations -- in short, anything that slows down the work horse and make them look productive in the process.

It's at least a unicorn, so companies shouldn't worry about hiring any 10x developers because they are THAT rare.

What they should do is avoid the developers that actually cost productivity. I'm a 10x developer compared to someone else not because I'm 10x average but because there is a 1/10th average dev there.

I'd say try to find the people who are just way over average (2x devs) and pay them twice the money if necessary. The problem is finding these people and making sure you aren't paying someone average twice the pay.

I think it depends on Industry / Role. A creative person in Advertisment or a good chip design engineer or someone great with Algorithm are often worthy of 10 or 20X compensation. Whats wrong is that many people think 10X guys can exist on Application layer / Front end. I think its very hard to do that

Of course it's hard to be 10x there. The same way it's hard to be 10x on the algorithm side. It's also a matter of scope - if you have a giant backend, and your frontend is a single text box, it's hard to tell if somebody is 10x. As the FE scope grows, you start seeing the differences.

In my experience, 10x programmers are hard to manage, they complain all the time, no one wants to work with them, their ego gets bruised easily.

But you keep them around because they seem really smart until you look at overall work produced. They might produce 10x work over a weekend but over longterm, they hardly produce any more work than average programmer.

In my interview process, if anyone even slightly hints that they are smarter than average, I end interview immediately. My team is composed of average programmers who get along and have fun working together.

I heard a joke once : Complicated problems requires complicated solutions. Unfortunately, all problems are a bit complicated if you are a bit thick.

The gist is that complexity grows faster than it needs.

Ignoring people that can't make things over a certain threshold, there is a large group of programmers that can make things work, but are not able to build things clean enough or put in the effort required to build testable and maintainable code, simplify support and reduce runtime costs.

Knowing when to stop and what to spend some extra time on is also important.

I'll hesitate to add reducing future development costs, because I've seen too much overly complex code written in a misguided attempt to handle unknown future requirements.

All these costs can easily build up to 10x over time.

A factor is that a team probably smoothes over the effects of one or two bad coders in a way that it's not noticeable at short term - the code is delivered and the worst bits are plastered over, but the long term performance is reduced.

Preferably the requirements are explored by the team with the stake holders.

The 10x effect is not on the immediate output of a particular development task. It's the lifetime value/cost of the choices made. In this respect there are many 10x developers, the ones who can factor complexity into a composition of conceptually and realized simple components. This works if they're presence is early in development, otherwise you may need a 20x to turn a 1x codebase into a 5x one.