[johnsmith1840]

I believe in a 10x because it's everywhere.

It doesn't mean more work it often means creativity.

For example when I was an EE I worked at a company that had spent nearly 8 months, 50k on consultants, and easily 3 peoples full time for a lot of effort plus the testing side.

I swapped that 800$ board out for essentially a lightbulb. Did identical work <50$ and was more reliable. That simple change was easily a 10x improvement if not more because the logistics of that one board was absurd.

I'm proud of that EE work but code is identical. I would never call myself a 10x developer but I've wiped entire code bases more than once.

Maybe I have "10x" moments? But to say this isn't a real phenomenon means you're in a super structured and political enviroment.

[pmontra]

I probably had that kind of 10x moment yesterday. I spent 2.5 hours analysing a feature request and I eventually advised my customer to think very carefully about it: it might solve a problem but the implementation time is going to be long, even with an AI, because of actual development and the time we will spend in testing it. Furthermore the new infrastructure will have recurring costs higher than what it saves. My advice is not to proceed. 2.5 hours vs 25 or more. 10x.

[godelski]

  >  2.5 hours vs 25 or more. 10x.

My point is that these 10x moments aren't sustained. When we're talking about a "10xer" we're talking about someone over a longer period of time.

For "in the moment"s and short term projects, 10xers certainly exist. There's definitely things I can do in a week that would take juniors more than 10. But for bigger projects? Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years? I'd really doubt the latter and the amount of things I can do in a month that a junior can't do in 10 are a whole lot smaller than what I can do in a week that they can't do in 10

[ytoawwhra92]

> Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years?

I briefly worked at an organisation where I was consistently and sustainably able to ship in two month blocks what other teams of 3-6 engineers at that organisation could not successfully deliver at all. I would consider myself around 75th percentile productive compared to the industry, but in that specific organisation I was at least 10x as productive as the median engineer - regardless of their seniority.

I think engineers tend to form clusters where everyone is roughly as intelligent/competent/productive as each other. Outliers tend not to join the cluster, or they leave quickly. I've seen this happen at the level of a company, but also in larger engineering orgs at the level of a team or group. High performers don't stick around when their median colleague is a low performer and vice versa.

Perhaps you've had the good fortune to work mainly in organisations with a high competency floor. Looking around, you may not see anyone who's 10x as productive as anyone else, but maybe you're ignoring that everyone is in the 90th percentile of the industry.

[johnsmith1840]

You can but not the way you're saying.

Once was part of a team where a mid level guy spent a year building/heavy maintenance of some catastrophe of a solution. They literally had the end users copy and pasting hundreds of commands from a generated excel sheet of a command per core (shudders). I spent ~2wks on a different architecture that was a massive improvement we abandoned their code base. He quit like 4 months later to join some faang. Granted that 2wks of work was on top of a distributed cloud infra that took me 6 months to build.

So yes, a skilled dev might skip entire months of work someone else would make.

What you seem to be describing is a companies skilled engineer designs something and passes down the spec. The guy making the spec is the 10x guy. For large projects it's even more pronounced. The article literally described someone who wasn't skilled they simply knew how to smooze the MBA's and a company with poor engineering leadership.