Hacker News Reader

Comment by marcus_holmes | Hacker News Reader

In my experience, the 10x programmer is a bit of a myth. Where I have seen people do some incredible feats of productivity, it usually came with a clutch of bad stuff, too. Like:

- they didn't work well with others and soaked up a lot of management time dealing with their shit.

- they had really limited areas of expertise where they were amazing, but couldn't fill in for a sick colleague.

- they worked in 2-3 day sprints for ridiculous hours, and then stayed home or might as well have.

I'm sure there are incredible people out there who can 10x and also be great team members, and I'm sure management are idiots if they don't pay them 10x.

But in my experience, the people who claim to be 10x are usually just insufferable egotists who have no idea of the pain they cause for everyone else.

View on HN

The 10x thing. Here's what I usually say about that:

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 ]

> well, we're all adults and we understand how statistics and distributions work.

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

I've studied power laws for a half-decade now and I still don't think I really understand them in my gut, to be honest

There are plenty of 10x or more effects. Anything with a binary outcome can be considered as such. If you measure a person's productivity along those lines, you will get 10x or more output. Also, this characteristic isn't restricted to programming. Furthermore, it is probable that someone can be -10X.

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.

I'm of the opinion that many people can be that 10x programmer. But there is a lot of 0.1x positions.

I think it depends on perspective. I don't think there's a 10x programmer, but I've worked with plenty of 0.1x programmers. If your organisation is not doing a good job of managing your developer team you may have a very skewed view of what 1x really looks like.

I've been 100x or 1000x in certain situations. Two examples: a solution required a recursive descent parser which no one recognized or knew how to implement, and another time a team fought a bug in some Java code for weeks, but none of them understood thread safety. So in these two instances, I've done things other simply couldn't. Not because I'm special in anyway, just because I had some experience these others lacked.

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've worked with plenty of 0.1x programmers

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 worked with this type. In this case very outgoing too and favoured by management. Man that code though! That code!

That's my impression too. It's not that good programmers are immensely more productive than decent programmers, it's that bad programmers are very bad. Not only can they just not do certain things, but they leave messes that others have to spend time fixing.

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.

If everybody around them is a 0.1x programmer, the 1x programmer is effectively a 10x.

What makes a programmer a 1x? Can you give examples?

> In my experience, the 10x programmer is a bit of a myth. Where I have seen people do some incredible feats of productivity, it usually came with a clutch of bad stuff, too

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.

they worked in 2-3 day sprints for ridiculous hours, and then stayed home or might as well have.

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.

it's not team-oriented behaviour. I'm not talking about face-time, but about having the attitude that you're part of a team.

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.

You know that famous inverse square root code? Apple basic?

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..

99.9% of modern software does not require that level of cleverness. Also, the fast inverse square root code is a poor example as it's:

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.

Metaphorically speaking, some mountain routes require a very, very good climber to scale. If it is a team that you are trying to get to the top, that amazing lead climber still needs to throw a rope down to the rest of the team.

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

"team-oriented behavior"? So the talented individual gets to write all the code and explain it to other people at the same time?

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.

This is not 10x, this -10x. If a developer churns out tech debt in a vacuum, they're a liability, not an asset.

The parent post seems to assume that a "heroic sprint of productivity" would not include communication and documentation, i.e. that productivity only means coding. I don't see that assumption reflected in the grandparent post, and moreover if you don't consider communication productive in its own right, you're going to have much bigger problems than people taking a day off.

> In my experience, the 10x programmer is a bit of a myth

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.

It doesn't have to be 10x. I think 2-3x differences are far more common but even they aren't typically compensated at that multiple in the market.

I rely on your experience for the non-existence of the 10x dev, but I've seen a x2 dev first hand, at young age. One of my interns did the same work in 3 months as the other in 6 months, plus various bonuses: Refactoring of old code into readable one, introduction of Kotlin, more unit tests, interesting discussions at lunch with other startups... Some people are amazingly smart.

yeah, I completely agree. There are people who are amazing at this out there. But they tend to be pretty humble about it, too, in my experience. And the best of them are really, really, good at bringing the rest of the team up with them.

Maybe the coefficient is just not efficient

"In my experience, the 10x programmer is a bit of a myth. "

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

Let me guess - you don't work on app layer or front end? :)

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.

Maybe I haven't met a true 10x programmer but met plenty who pretend that they are 10x. I would say those 10X programmers that I had "pleasure" of working with, are net negative to overall productivity.

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.

This. And also, code if this kind if 10x developers is often unmaintainable and untested, which brings 100x effort for their teammates in the future.

My experience is that the long term effects are more than 10x.

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.

Another thing often happening, is features coming down to developers, who by slight alteration can be trivial to implement. This usually happens due to missing domain knowledge of the management and sales (and a lack of insight regarding this lack).

I'd say it's a process error if the requirement specifications are locked at the point they reach a dev team.

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

> 10x programmer

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.

Reply on news.ycombinator.com