[itsibitzi]

Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience.

The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked.

I feel this "10x programmers are a myth" attitude comes from a good place of wanting to promote harmonious working and skill-up junior engineers, but it seems so totally detached from reality. I'm not sure the "benefit" of propagandizing against talented assholes is worth the cost of demotivating people who might be inspired that they could become a 10x engineer.

[NineStarPoint]

Realistically, I’ve always found it a weird sentiment more because issues caused by software developers are not of the “this person is 1/10 as productive as this other person” type. A bad developer isn’t a low positive effect on a project, but an active negative effect. As such, you can put literally any Y for a (Y)X programmer, since the scale of how inefficient a programmer can be goes up to infinite.

I think the pushback against 10X programmers comes primarily from the fact that many programmers who look good to managers (constantly push out new features) are in actuality an albatross around the necks of the other programmers who constantly have to fix the messes they create (in reality, a negative on team-wide production). What matters more to me in a teammate than how productive they are is to ensure that they are on the positive side of the scale at all, which the perceived 10X programmer is often actually a failure at.

Though I’ve definitely met people who just have such a wide knowledge base and think so quickly that they are in fact 10X as effective as a standard productive programmer, so I do understand where the idea comes from.

[pjc50]

More people should be aware of Comrade Stakhanov, the "10x miner": https://en.wikipedia.org/wiki/Alexey_Stakhanov

> In 1988, the Soviet newspaper Komsomolskaya Pravda claimed that the widely cited achievements of Stakhanov were puffery. The paper insisted that Stakhanov had used a number of helpers on support works, while the throughout was tallied for him alone. Still, according to the newspaper, Stakhanov's approach had eventually led to increased productivity by means of a better work organization, including specialization and task sequencing

Exactly the same discussion, except there it was tonnes of coal which can be easily and unambiguously measured. But they can't be easily attributed. How much of his work was really that of his team? And how much of it was simply inflation by his managers for propaganda purposes? And how much of it was, underneath all the propaganda, real process improvements?

[CRConrad]

TAN: I fearst heard of "Stachanovism" over forty years ago, in my teens. Some time before that I had read an anthology of American folk tales, so to me Comrade Alexei Grigorijevitj was always kind of a Soviet version of John Henry. Made it easier, when I later found out, to accept that Stachanov was also at least in part a myth...

[cutemonster]

Yes attribution can be hard.

At the same time, if one compares shoveling coal and laying bricks with software, then it'd be good to smash and destroy bricks, throw the coal back into the mine, raze houses. (Reducing the amount of code)

Software would be more comparable to designing the coal mining site, or architecturing a city (but not building it). And then maybe it's simpler to see, that individuals sometimes can have much impact.

[Aaargh20318]

> The benefit of talented engineers comes from the fact that they avoid costly pitfalls - not that they pump out more code per hour worked.

Not just avoid pitfalls, being able to put together a good architecture is a huge factor as well. The effect is cumulative. If you have a good design to begin with, everything becomes easier with less risk of bugs. The result is that implementing new, or changing existing functionality takes less time.

The 10x developer doesn't write 10x as much code, (s)he will probably write less code than the 1x developer.

[llaolleh]

Exactly. It's not how fast someone churns out code but how well thought out/elegance in approach that delivers this 10x value.

Instead of writing entire systems from scratch, maybe you have enough experience or familiarity with well known techniques and libraries to ship faster.

[bogwog]

> (s)he will probably write less code than the 1x developer.

Or better yet, remove code.

[pjc50]

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

[jimbokun]

This needs to be required reading for every first time, non-technical manager of software developers.

[dijit]

I always read it as a direct comparison though.

It doesn’t matter if I have better experience or I can contextualise intent better; the phrase “10x” means it would take a team of 10 to do it, in the time, scope, budget (whatever).

But there are major reasons this could be the case, if I’m on my own and I know the direction then I don’t have to quibble about what framework to use, how to name my variables, what I consider “proof of concept quality”. You just get your head down and do it with the entire scope and progress in your head at once.

No infighting about semantics, no deeply technical progress reports or trying to subdivide tasks which are not inherently subdividable.

More people is more communication and it’s quadratic.

[obedm]

The author exactly says this "two engineers with the same experience".

I'm sure there are engineers that can create an architecture 10x better than mine.

But show me someone that can create UI 10x faster and I'll admit they're a God.

Some things can't be 10xed after some point. It just takes work.

Some things can be 10xed and some just can't. I find it silly to think someone can be overall 10xer at everything.

[michaelcampbell]

> Saying 10x programmers are a myth because it's crazy that someone could do in 1 day what another could do in 1 week makes the assumption that both programmers in the example have the same amount of context, background understanding, and experience.

Yes, because that's how it's always presented. And if it's not, then it's also a myth because then it's not a 10x dev, it's 10x context, background understanding, and experience.

Either way it doesn't hold water.

[Jensson]

> it's 10x context, background understanding, and experience.

A person who is able to build 10x context, background and understanding is a 10x developer. Most people lack the ability to do that. Your post makes it seem like you could give those traits to anyone easily, but it doesn't work that way building the right mental models and being able to generalize your knowledge are key factors in talent.

[t43562]

Why do people need to be motivated in such a way? Won't that just lead to a lot of disappointment and misery later on? Why isn't "being a good programmer" something we should admire?

[JoeAltmaier]

Of course one programmer can create 10X the code of another. The limit isn't how fast they type. Its how correct the code is, and how much it leverages what you have and what you'll need. And that results in 'pumping out' more code per day. Whatever the reason (context, background, experience)

[kiklion]

> The limit isn't how fast they type. Its how correct the code is

And how good your autocomplete tools are, or you repertoire of code based to copy from.

[908B64B197]

> I feel this "10x programmers are a myth" attitude comes from a good place of wanting to promote harmonious working and skill-up junior engineers

When comparing juniors you observe the same distribution.

I've met 10x straight out of college who ran around other new grads.

[WhompingWindows]

1 day vs 1 week: wouldn't that make them a 5X engineer? That's half of the advertised 10X...