Hacker News new | past | comments | ask | show | jobs | submit login
Busting the 10x software engineer myth (swarmia.com)
155 points by albertom94 26 days ago | hide | past | favorite | 344 comments



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 totally agree, but I think you can use examples closer to home.

Carmack could build a video games which is 100x across a number of metrics (quality, cost, time to deliver) than I could. Still too far? Pick your field, there'll be experts.

You can get even closer to home. After 20 year, I really feel like I'm at least 10x developer across a number of metrics (e.g., value to my employer, amount of complexity I can manage) than I was when I started.

Also, some developers do more harm than good. An employer would literally be better paying them not to do work.


I always use competitive coding as an example. There are children in Ukraine / India / Russia / wherever who I'm sure will always be able to whoop my ass in these competitive coding things. I try really hard and get nowhere, and when I look at their submissions it's some inscrutable / clever thing that solves the problem orders of magnitude faster than I could ever do.

The only way through this all is to recognize that it's okay to feel stupid, even if it's pretty much all the time. I'd rather feel stupid and challenge myself than sit around bored (e.g. with Monolith Maintenance).


Your case of Carmack is illustrative.

To achieve 100x, consider what he was doing:

- writing a first person shooter (Castle Wolfenstein 3d)

- writing a first person shooter (Doom)

- writing a first person shooter (Quake)

... you get the idea.

Now, there was enormous leaps in maximal utilitilization of hardware, but do you notice a pattern? The requirements are basically fixed.

Most 10x I've achieved in a short fashion or observed was due to some similar parameters:

- the requirements were stable

- the basic problem was done before and practiced, and implementaiton was a variation/improvement of the previous

- solo or very small development team where greenfield imposed little barriers


Commander Keen was the first side scrolling platformer for PC (side scrolling was hardware accelerated on consoles, so PC games didn't have it before this) and released 1991. Wolfenstein 3d was the first fps and released 1992. Both of those were revolutionary and combined is more than enough to put him way above most other game programmers at the time.

And you know, at the time he didn't have any experience! That was his first few years as a professional programmer! So your hypothesis that he was only effective since he worked in a domain he had tons of experience in is wrong! He had less experience than most other programmers but was way more effective in many different areas.


Side scrollers have existed since the Apple II on "PCs". I highly doubt that 1991 was the first side scroller on ibm pc.

Wolfenstein was not the first 3d fps on ibmpc, and certainly not in "PC" land. Skyfox existed on the Apple II, and battlezone likely was ported at some point.

Carmack was fantastic, but again his "requirements" are static and he is a dev team of one.


A lot of early jump & run games worked on a screen-by-screen basis (Prince of Persia, Lode Runner, etc) rather than actually having smooth, NES-style scrolling.

In any case, this Wikipedia article [1] backs up that the only real predecessors of Keen on PC were early-80s console ports that were extremely limited in other ways, like having boxy, low color count graphics.

[1]: https://en.wikipedia.org/wiki/Side-scrolling_video_game#IBM_...


seadragon on the apple II did scrolling, as did a lot of shmup and shmup ports.

I've never written a side scroller so I don't know how much of the gravity/platform mechanic complicates the scrolling, but I imagine it's about the same thing as shmups with hitboxes, sprites, etc.


Mazewar was the first FPS, but Wolf3D was a totally different class of game, and every FPS since then has been an imitation of Wolf3D. Agreed about CKeen.


> Carmack could build a video games which is 100x across a number of metrics

But even Carmack couldn't crack Steve Jobs stubbornness.

Sometimes being 10x is only a matter of being free to help the best you can.

EDIT: where Carmack shows that he is well above average is not in coding, but in being extremely pragmatic and thous being able to extract good, almost unbiased, information out of every discussion, even the more unpleseant ones.

---

Part of his method, at least with me, was to deride contemporary options and dare me to tell him differently. They might be pragmatic, but couldn't actually be good.

"I have Pixar. We will make something [an API] that is actually good." It was often frustrating, because he could talk, with complete confidence, about things he was just plain wrong about, like the price of memory for video cards and the amount of system bandwidth exploitable by the AltiVec extensions.

People were backing away from us. If Steve was mad, Apple employees didn't want him to associate the sight of them with the experience. Afterwards, one of the execs assured me that "Steve appreciates vigorous conversation".

Still deeply disappointed about it, I made some comments that got picked up by the press. Steve didn't appreciate that. The Steve Jobs "hero / sh*head" rollercoaster was real, and after riding high for a long time, I was now on the down side. Someone told me that Steve explicitly instructed them to not give me access to the early iPhone SDK when it finally was ready.


> But even Carmack couldn't crack Steve Jobs stubbornness.

I honestly don't understand how this is relevant.

Carmack is 10x in coding and designing software. Jobs was 10x in PR and persuasion.


The point is he wasn't when he worked with Jobs.

Carmack is exceptional, not just 10x, but how many above average people work with a Steve Jobs and can't prove it and do not even realize it?

Carmack is not an actual good benchmark here, but even as good as he is, he met his kryptonite

Don't assume that great workers will perform great in every condition, because that's not a realistic assumption and only puts pressure on younger people for no reason.

We must not support the idea that if you're not Carmack you can't be worth (at doing your job. *only *) more than the others or the company's average.


"worked with Jobs"

What are you talking about, John Carmack never worked directly with Steve Jobs? He had his own company and he sometimes had to talk with Apple as a platform vendor, but they never worked together on a title. He didn't like Jobs as a person but that is another story.


Carmack literally talks about working WITH Jobs, but random HN user says he didn't.

OK!


John Carmack ran a video game company. Steve Jobs ran a platform, the Apple. Therefore John Carmack sometimes talked to Steve Jobs about things he needed from the Apple platform. John Carmack had a very negative experience in those interactions, yes. But John Carmack never worked with Steve Jobs on any project. Steve Jobs was never the boss of John Carmack.

If you disagree please link an article where it says that they did work together on anything and that during that project John Carmack's performance was significantly reduced. I haven't found such an article, and it would be strange since they never worked at the same company.

That he did a few keynotes at Apple isn't really working together. And him refusing to take a keynote that would force him to reschedule his wedding is just him being healthy and Steve Jobs being an ass, I'd say that is evidence that Steve Jobs didn't really have any power over him.


> If you disagree please link an article where it says that they did work together

It would have sufficed to read the Carmack post.

Seriously, random internet guy, he literally *said it himself*

> When NeXT managed to sort of reverse-acquire Apple and Steve was back in charge, I was excited by the possibilities of a resurgent Apple with the virtues of NeXT in a mainstream platform. *I was brought in* to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.

> I wound up doing *several keynotes with Steve* (see the word WITH?), and it was always a crazy fire drill with not enough time to do things right, and generally requiring heroic effort from many people to make it happen at all. I tend to think this was also a calculated part of his method.

-- John Carmack

I've specifically said WITH not FOR.

Please random guy, read before speaking.


> But even Carmack couldn't crack Steve Jobs stubbornness.

Not sure that's a bug.

Seems no matter what Jobs thought, Carmack kept bringing value and shipping great software.


I guess this all depends on your definition of 10x. It sounds like you are saying 10x the average person rather than 10x the average person who works in that field.

I'm a 10x developer if we count non developers. I am not if we could people who work as developers. Likewise there are expert marathon runners who are 10X, or more, than the average human. But there are not marathon runners who run 10x faster than other professional marathon runners.


Claude Shannon, Dennis Ritchie, Vitalik Buterin, Jeff Dean are all 10x programmers. Let's not pretend they dont exist


Perhaps. But is it meaningful to talk about these incredible outlier cases when considering how you structure an engineering organization?

I think there are two kinds of companies that make tech:

1. Companies where all of the technical problems they need to solve can be solved by typical engineers.

2. Companies where some of the technical problems they need to solve are too difficult to be solved by typical engineers.

In the latter case you do need "special" engineers and you need to point them at these problems. But what percentage of companies fall into category #2?


3. Companies that have technical problems that can easily be solved by typical engineers but not noticed and articulated by typical engineers.

Which is most of them. The main value of "special" engineers come from them pointing you to the right problems. Notice how all of Ritchie, Shannon, Dean and Buterin certainly fall into this category. They were all technically proficient enough, but that's not the point. A seasoned veteran would have coded circles around Buterin at age 20, which is when he invented Ethereum. The point is that the seasoned veteran didn't invent Ethereum. Similarly, Shannon's most influential work (that paper that basically invented information theory) is fairly elementary, and basically any geezer with a relevant PhD had had the technical chops for the paper. But they never would have written that paper in a million years.


10x what?

As far as I'm aware, Shannon wasn't even a programmer.

I'm sure Ritchie was pretty good at coding in the language he invented; AIUI, that language is pretty similar to the assembly language of the machine he designed it for.

I don't know anything about Buterin and Dean.

I'm sure these people all had brilliant ideas and insights, that I couldn't begin to match. But given an arbitrary dev task, I doubt they'd come close to 10x the performance of a reasonably competent dev.


'dev task', 'shannon wasn't a programmer', 'don't know about buterin, dean' -- There in lies your problem, seriously


Shannon was a mathematician, famous for his work on information theory. Wikipedia says he presented a paper on the subject of programming a computer to play chess. In 1949. It doesn't mention any other programming accomplishments. And as far as I know, there were no programming languages at that time.

And if my "problem" is not having heard of Buterin and Dean, I reckon myself a fortunate fellow - I can think of worse problems.


> But there are not marathon runners who run 10x faster than other professional marathon runners.

It’s true that they don’t run 10 times as fast, but the marathon runner that is 1% faster will finish 10x more races before the slower one (YMMV depending on stdev).

Similar in software development, picking a 1% better local solution often enough can make the global result 10x better due to the complexity of the systems.


This example holds true imo. There is a world of difference between a 2:10 marathoner and a 2:30 marathoner. Same as a 4 min miler and a 4:30 miler, etc.

Because of diminishing returns, improvement can still be seen as potentially some kind of multiple in many skillsets.


So 1x devs exist? I agree.


> Marathon runners run 42 km in like two hours but it would take me days to finish the same distance...

Not really. If you walk at an easy pace of 2 miles per hour, and start at 6am, you'll be done in time for an evening meal. At 3 mph, you might even make afternoon tea.

The world record marathon times are, in fact, only about 4-6x what you can do as a walking human being.


Correct - and if you compare world record marathon runners with average (but seasoned) marathon runners, the difference is even smaller.


Specifically, RunningWorld.com took data from 107.9M runners over 70,000 events over 209 countries over 32 years and found the "average" finish time was about 4:32hrs. The men's world record is ~2 hours.

https://www.runnersworld.com/uk/training/marathon/a27787958/...

(That link has a video of people on a giant treadmill, moving at Kipchogi's world record pace, trying to keep up).


Time wise, absolutely true, but as someone who is a reasonably seasoned runner I can say my 3:30 marathon feels lightyears away from 2:00. It doesn't sound 10x harder, it sounds impossibly harder.


so in the context of TFA, what really needs to be asked is not "are some people massively better coders than others?", but rather "how difficult is it to progress from the equivalent of a 3:30 marathoner to a 2:00, as a coder?"

I don't know the answer, TBH. I've been a programmer for nearly 35 years now, and at times along that journey I've been the 10x coder. But I'm not anymore (just like I can't go sub-3h for a marathon at this point), despite knowing a lot more and being better by some metrics than I was during my 10x periods.


Maybe what needs to be asked is

"If you're okay with the message getting there in 3 and a half hours instead of 2 hours, do we really need to fetishize 10x performance?"

YAGNI is a way stronger principle to base your success on than finding or training unicorns.


> It may take a world-class musician a week to write a masterful symphony but it would take me way longer.

But are you a world-class musician yourself?

Yeah it would probably take me a week to run a marathon, but I've never run anything so it's not a meaningul comparison.

In all your examples you're comparing amateurs or even non-participants vs. the top professionals. Of course there is a huge multiplier, up to sometimes infinity.

That's not the typical usage of "10x developer" though. The baseline comparison isn't random person on the street who is not a developer. The comparison is other professional developers who are gainfully employed in the field.


I've worked with hundreds of average (professional) developers over the years, and I've only met 1 person who was a 3x developer. I've met several 2x developers and lots of 1.5x developers. I assume a 5x developer exists, but I doubt a 10x does.


When your baseline is 0.1x developers, a normal developer can be a 10x developer.


The baseline is 1x, that's what 1x means.

i.e. Your regular professional career developer who does good solid work and is always rated "Meets all expectations". That's the 1x.


My baseline is the average.


I think the point of x10 devs is this doesn't occur in other fields. It's like a HR Moore's Law.

I've always understood it as: if you step back and see the easy way, it's easy to be x10.

But most jobs are dominated by actual unavoidable straightforward work. Another exception is mathematics. You can certainly have a x10 mathematician! But it's not a mainstream job.


> this doesn't occur in other fields

It absolutely does, just look at surgeons.


I want to find the 10x surgeon who can complete a one-hour operation in six minutes.


The best operation is the one not done. Often the operation is unnecessary.


I don't think the metrics is always speed. I think it is efficiency (quality_of_work.hour).


The reality is you DO have 10x devs, hell you have infinity-x devs, because there are zero value devs - epitomized by the bullshit promoted by stupid start-ups like Swarmia, and next to that, by basic mathematics, anything positive represents a infinity-x improvement.


10x (or more) engineers in both hardware and SW exist. I've personally known more than a few, they are humbling, and I was pretty good myself at the time.

SW is too time consuming, I think, for it to really show, and tools help even things out, but I think math shows that even 100x people exist - the von Neumanns of the world. Maybe they don't exist any more, but we had a bunch of them in the 1900s and it's inarguable that they were at least 1-2 orders of magnitude above the rest.

That said, there's a ton of people in the field who now focus on image management so heavily that the numbers of _apparent_ 10x are really skewed. If you're willing to engage in engineering fraud, overselling, etc. you can seem to be one of them pretty easily in most contexts even pushing the most outrageous crap/fraud as something it's not. I feel like ML particularly enables this. I am dealing with two of these guys now, and honestly, it's so tiring dealing with the low-cost-to-produce/high-cost-to-analyze asymmetric warfare that frauds in engineering create.


What do the two guys produce that's hard to analyze?


It's a volumetric warfare. Demonstrating that their output is just a rudimentary assembly of stuff that doesn't do what they claim after the fanfare and announcement emails is much more work than it costs them to produce this stuff.


10x is often used to suggest that one only seeds a single 10x developer. This makes as much sense as the army being okay with squad made up of one 10x solider.

Yes there are 10x solders but their impact is measured by their impact on the unit. IMO this is the only sensible meaning of 10x in large scale software development.


"myth" is just another ruined word.


Hard agree.

For many, I wonder if the denial stems from imposter syndrome and a lack of self-confidence in their own performance at work.

I suppose in that scenario, the idea of 10x-ers would be quite uncomfortable if I felt like everyone was referring to my output as the baseline?


This is so obviously true that I laugh whenever I read the “10x software developers doesn’t exist” articles. Typically written by average developers with an axe to grind.


> Great chess players beat amateurs at least 99 times out of 100 so must also be 10x in comparison.

Absolutely. Chess is very hierarchical. I would say true amateurs will literally never beat a grandmaster, and high school champion-level (not prodigies though) can only beat a grandmaster if the grandmaster plays very weakly (vastly underestimating them, not truly playing their best, or having their guard really, really down).


In Go, for example, for the professional ranks (1 dan through 9 dan) each rank should win 70% of their games against players from the next rank below.


> Marathon runners run 42 km in like two hours but it would take me days to finish the same distance...

This doesn't take away the core message of your post. Most marathon races are time limited for logistics reasons - to open streets to traffic. Give or take 6 hours.


10x is real but I think the more compelling question is how low a bar of competency is allowed to work in the profession - and what is the average level of competency in the programmer market.

"Certifications" doesn't get there - too easy to just game a multiple choice test. I would like to see a formal education + testing requirement (ala Doctors, just not 10 years!) Essentially, a barrier of entry for serious programmers. That would ultimately come with a high minimum salary without having to get hired at faang.

College accreditation doesn't cut it either. I work w programmers with an MS in CS. Programmers are kinda impressed. Managers could care less.

The insanely high demand for labor and (always present) priority to reduce labor costs however encourages the entry of boot-camp you're hired on the low end of experience/competence.


I love it! Artificially constrain the labor supply with licensing. It would be incredibly lucrative for programmers. As a bonus, it would increase the prestige of our profession. Of course it would be a terrible deal for companies and quite bad for the economy.

The fact is that there are many types of applications where a high level of expertise is not needed. Eg. websites for small businesses. The client/end user doesn't care how cleanly architected or efficient or even bug-free the codebase is, and it's a better deal for management to pay some freshly-minted bootcamp grad 50k/yr to hack away than drop 6 times that on a 10xer.


Wouldn't winning 99/100 be a 100x chess player?


Depends on how much the 1x wins, and that depends on who they play, where, when, in what state of mind, with what extra resources…


They play the same games in the same time.

https://en.chessbase.com/post/carlsen-s-70-board-simul-in-ha...

Here we can see Carlsen being more than 70x as efficient as his opponents. He won 67 of them and lost 1 which is why we can't say that the 70 he faced together was as efficient as him.


The problem is that you can't measure a developer. So you can't say someone is 10x faster or better. If you add a bench-mark like how many LOC is written per day, most will exceed at that benchmark, but the overall quality will go down.


> So you can't say someone is 10x faster or better

You can absolutely measure something.

I have a colleague going through this right now - he's got... 24 years of experience in software - mostly web - across multiple problem domains/industries. He's now on a web team with someone who's done windows desktop software for 15 years, someone else who graduated from high school 2 years ago and has never worked anywhere before, someone else who has a few years of some web experience but has never actually shipped anything remotely close to what the team is trying to do.

There's more, but... the mgt wants to treat everyone as 'equal' and having an 'equal voice'.

So... they need some new web service. "Let's use React! Let's use Dart! Let's use foo!"

Mgt: "OK - well... let's have a 'shoot out' - everyone research their ideal and we'll present findings!"

My colleague: "Hey - here's this. I got this done in a couple days - there's tests, docs, works with the existing infrastructure, and has some sample data for you to play with".

Weeks later, others: "Hey, that's not fair, you already knew some of that. I'm not an expert in $foo, but heard good things about it, and people at google use it, so we should too! I just need a few more months to get up to speed, then I can show the rest of you how good it is and why we should use it."

Someone being able to accomplish stated goals in a few days, where other people on the team are not even sure what terms to google... Yes, there are people who are "10x developers".


That sounds like a senior engineer vs junior engineer experience level.

The term 10x engineer is generally used differently.

Though I guess the reason for terms like that might just be related to how many inexperienced people get senior level jobs.


The comment I was replying to was "The problem is that you can't measure a developer."

You can measure. One way you measure is years of experience. Another can be time to deliver against a spec. Another can be number/size of defects. Another can be time to remedy defects.

Yes, it's "junior vs senior", but their management is explicitly stating "everyone's experience is relevant, and everyone has an equal voice" and so on. No, the person who has literally never contributed to a production codebase should not have an equal say in the technology stack choice. Their voice is not 'equal' to someone who has delivered consistently for 2 decades.

And... yes, it's largely bad management. He's looking to move. They had rocky mgt for... a year before, but it was tolerable. Leadership changed and my colleague stuck around the last few months to see if things would get better, but they're getting worse.


> That sounds like a senior engineer vs junior engineer experience level.

I've actually met junior 10x engineers, I could tell pretty quickly that they were better than me. I've also met senior 1/10x engineers!

Working with a junior 10x engineer is humbling.

I remember starting out at my first job, realizing I was working with people way better than me (my first office mate had 2 PhDs, IIRC Chemistry and Physics!), but slowly I climbed up the ladder of competence and became that software engineer who was doing the Really Cool Stuff.

Then, new grad joins, and he is quite obviously a full standard deviation to the right of me.

Like, shit. Sure some architect whose name is in Wikipedia, yeah they are better than me, and I've been honored to work with multiple people of that caliber, and when you work with someone whose career is regularly described as "ground breaking", you don't even try to measure up, ya know? But, when someone fresh out of college starts pumping out better code, faster, than anything I can do, just, takes a bit of mental adjustment.

Intellectually, it shouldn't be surprising, after all if there are smarter people who are older, than there are smarter people who are younger!

The one guy I am thinking of (who might be reading this, you know who you are!) is also humble, and eager to learn from everyone around him. It was a delight working with him almost a decade ago, and his career has been great since then.

Thinking about it, I don't even know where I am on the 1-100x scale. I know people who are obvious 100x developers who are the literal one of only a few dozen people in the world who can do the things that they did. During my career I have been responsible for the success of multiple projects that would've fallen to pieces w/o me, and while I was a blatant bus factor of 1. But even then, in all those projects I worked with a group of amazing developers, we all kind of brought different 10x skills to the table, if that makes sense.

Actually, when I was the Bus Factor of 1, it wasn't for my code. The handful of 10x people on the projects were turning out much better code than I ever could. My 10x contribution? I organized, lead, and figured out what code needed to be written, designed systems, and saw the interconnections between the work the various 10x+ devs were doing. My real contribution was spotting patterns, good and bad, and using that recognition to get ahead of future problems, or to organize efforts to put code in place ahead of time in anticipation of future needs.

Heck the project I'm leading right now, it started because I saw a pattern in existing work flows and I started thinking if there was a way to optimize those workflow through better usage of data structures and automation.

Maybe I'm a 10x pattern recognizer.


I recommended a graduate hire once with "he failed all my questions, but he's clearly very smart". Fortunately I was right and he was great to work with, and I'd recognized that my questions had been expecting a particular curriculum.


> Thinking about it, I don't even know where I am on the 1-100x scale.

Where you are is dependent on the rest of the team, and the structure of the process. The notion of "X" times as a measurement implies a comparison to others. Posted elsewhere... I've been the slowest/least-productive on some teams, and I've been the 'rockstar/ninja/10x' on others - in one case, during the same time frame, just different teams.


Schrodinger's project management: developers are measurable as long as they don't know they are being measured.


You might be joking but it actually has a name: https://en.wikipedia.org/wiki/Goodhart%27s_law

Well, your idea is probably closer to the Marilyn Strathern definition.


Better play it safe and commit more often.


I used to 'craft' commits but more frequent WIPs is what the people (who write the checks) want to see.


Cue the link to the story of Bill Atkinson‘s “-2000 Lines of Code”:

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


You can't "measure" a session musician either. And yet some of them take hundreds of dollars an hour to be there for a recording, so clearly there is a way to know


We are exposed to music so much that even someone who don't know how to play an instrument can tell the difference. So the average Joe can tell the difference in for example talent shows. Now imagine a talent show with programmers/developers, we kinda have that already with hackatons, but then it becomes more about the presentation, the actual code - if any code exist at all - is an absolute "hack".


If a session musician charges by the hour you know they aren’t good OR haven’t been recognized yet. Day rates.


When a wise man points at the moon, an idiot looks at his finger


Sometimes you can. At some point I worked as a consultant assisting a team that actually picked the next item from the backlog as their next task. All tasks were estimated before they were put in the backlog and assigned to someone. I would usually finish tasks in less than 30% of the esimated time, while some would use 3x+ the estimated time, and then only because they were receiving assistance a couple of hours per week.

The guy doing the estimages was evaluated based on his ability to estimate accurately, so he had to inflate the estimates beyond what would be reasonable.

This was in a country with really good job protection laws....


When a measure becomes a target, it ceases to be a good measure.


Can a 10x marathon runner finish 26 miles in less than 1 hour? How about 10 minutes? There _are_ gaps between skill levels, but from personal experience, no one is substantially worse or better. We are after all just flesh and bone...


> Can a 10x marathon runner finish 26 miles in less than 1 hour?

That’s the wrong analogy because marathon runners are already the 10x-ers of movement.

The average person could cover the distance of a marathon, but it would take them many days of walking and resting.

A marathon runner can finish a marathon in around 5 hours. That’s an order of magnitude faster than an average person, so yes, they are 10X-ers.

Most people can walk, but few people can cover so much ground so quickly. That’s the essence of the 10X designator.

The average programmer is not like the average marathon runner.


I think your comment inadvertently illustrates how much of this comes down to how you define the baseline. I think the comparison for a world-leading marathon runner shouldn't be someone who _never_ exercises but someone who's actually put some effort into fitness (say, an amateur runner) — yes, they're faster but it's nowhere near 10x[1] — just as our baseline for a 10x developer shouldn't be someone who's never written a line of code before but the median professional developer. It's easy to get an order of magnitude win over someone who's completely inept but once you get into more realistic territory you're chasing diminishing returns pretty hard.

The other big problem here is that you're talking about a complex skill but trying to reduce it to a single number. Tellingly, most of the 10x developer examples cited are cases where they know exactly what they want to do and have near-complete control over it, which isn't exactly how most developers work. It's really hard to quantify things like teamwork or the ability to distill what people need from what they say they need, and those are core skills for most of us in a way that optimizing a 3D engine is not.

1. I've done marathon length _hikes_ in far less than a single day, and I'm far from a hard-core athlete.


I think it is probably much, much less harder (as a young, healthy person) to get from relatively unfit to running a marathon in 4:20 compared to getting from that 4:20 to the 2:10 that the elite marathon runners do. It's probably a lot more than 10x harder to go from 4h to 2h, I think. I gained a lot of respect for them when I realized that my gym treadmills' maximum speed (20Kph, which I have never managed to hit for any significant length of time) is less than the average speed to hit the current world record times.


That was my experience as a cyclist, too — when I was in my 20s it was relatively straightforward to get my average for a 100mph ride with modest hills into the low 20mph range, while the people in the Tour de France are sustaining greater speeds over mountains. Going from that dedicated amateur level to even the lowest pro tiers requires both significantly more effort and a fair amount of luck in terms of genetics, being able to afford that time, etc.


> The average person could cover the distance of a marathon, but it would take them many days of walking and resting.

26 miles at 3 miles an hour is a bit under 9 hours. Throw in another hour for resting and the average person should be able to walk a marathon in 10 hours. Sure they might be sore afterwards but from what I heard marathon runners also need to recover after their run.


There’s a much bigger difference in ability going from a 2:30 marathon to a 2:00 marathon than going from a 3:00 to a 2:30 marathon. It’s not linear. But it’s also not relevant to the point the OP is making.


A 10x marathoner can achieve a qualifying time for their marathon far 10x faster than the average person who might not ever be able to qualify.

When you talk about a 10x programmer, you don't expect their program to run 10x as fast. You expect 10x the results.

A 10x marathoner could post the regular marathoners best times 10x as frequently throughout the year easily. His training runs would destroy regular runners PR's. No amount of work by the regular guy would allow him to produce a single instance of comparable performance.


This is annoying semantics, but sport is just as often about being very fractionally better and making a time fractionally smaller .. at the expense of huge amounts of effort. The same can apply in software too. I don't think it invalidates the metaphor as long as you can stop people interpreting "10x" to mean "there is some precise metric on which we can determine the average is a number X and this person is at least 10X".


The average marathon run time is about 4.5 hours. The world record marathon run time is 2 hours.

Most people who run cannot even complete a marathon. Then there are ultramarathons.


> Then there are ultramarathons

and then there's Mauro Prosperi


The only reason DOOM was finished in 1997 was because John Carmack recognized himself as the 10x developer and started living in-office until the game was finished. Obviously it's important to not let silly titles distract you, but stepping up to the plate like this is how organizations get stuff done.


And while there’s nothing wrong with people choosing to do that, there’s absolutely everything wrong with organisations that expect it.


Yes!

This is how bad organisations get stuff done. Good organisations don't run into these problems in the first place because they listen to their staff and don't set arbitrary deadlines*

* I have no idea how arbitrary the deadline for Doom was. But I've seen so many devs burn themselves out meeting deadlines that were pulled out of a hat by managers because it gave them the illusion of control


Most real 10x's work precisely when they decide to. If they are mistreated by their employer, other stand in line to hire them.

The crunch problem mostly applies to the average-and-below developers (possibly with the exception of some devs that give up leverage vs their employer somehow, by depending on them for a visa, only consider work in a given industry, etc)


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.


If we're taking about is just output on a larger macro scale, then yes, hiring enough people will replace 10x engineers.

But some things i think you won't be able to replace --

You won't be able to replace speed on short-term projects. Lots of people means lots of communication overhead, which really kills fast responsive speed. If you value time to answer, you'd prefer a small team of really smart people instead of a large team of average people.

You won't be able to replace the insights. Tasks and knowledge are distributed amongst many individuals in bite-size chunks, so you miss out on insights you only get when someone holds everything in their head at once.

You won't be able to have a small team / small company culture anymore. You have to be large, standardized, bureaucratic, catering to the least common denominator. And then make up for it with volume.


Just to give a concrete example: no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck. Throwing 1000 engineers won’t solve the problem.

I imagine within the tech world there are tasks that are ill defined and a small subset of engineers can solve, but a typical engineer may not have the background to solve it.


>no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck.

You actually hit this nail quite on the head with the example. The "10x engineers" get a lot of their "10x"-ness from creativity - most I've met are cartoonists, painters, musicians, writers, cooks - artists in general that love software as a way of expressing themselves and earning good money. The beautiful bits of code you get after are usually there because the starting point is "create it" not "implement existing solution/pattern".


I generally consider myself a 5x coder... I usually spend about 1/3 the day reading/learning and another 1/3 experimenting... only about 1/3 of a typical day will I be on-task, and usually still outpace my peers. This last 2-week cycle, I literally did all the assigned work, and refactored a few things that annoyed me in one caffeine fueled night.

I used to do design/graphix/ux work... that always interested me. Programming pays better, and I have a talent for it. I have spent time learning patterns, etc, but not through a formal education. I tend to just see a good way forward... creating discoverable code along the way. I find a lot of the time, the formal patterns tend to just make things more complicated than they need to be.

Just my own take on things. I'm kind of lazy in a good way. I have spurts where I will do a crazy amount in a short time, and those where I'm closer to coasting. Like many/most creative types, it varies.


This has helped me to understand this very problem (which I didn’t really know had a name)


Uh, you left out passionate lego builders (AFOL). I’m adding it for you.


> hiring enough people will replace 10x engineers

The math is not that simple. The output of a Junior engineer is much different from that of a Senior engineer. You can hire any number of Junior engineers you want, and they won't have the vision and seasoned experience of a Senior engineer for producing higher quality code with less technical debt.

Even among Senior engineers there are different grades of experience/competence/capability.


I think its important to understand there are also relatively high floors to getting certain things done well. If the engineer is too junior or simply not good enough, its not that you will get there slower, its that you may not get there at all. Or you get there slowly and with a very buggy or unmaintainable mess. Some engineers can even go backwards in that sense, attempting to optimize the wrong solution and spending months on something that in honesty can't actually be completed.


Cue the link to Mythical Man Month:

central theme is that "adding manpower to a late software project makes it later."

https://en.wikipedia.org/wiki/The_Mythical_Man-Month


I've had junior engineers outperforming senior engineers, even counting the hours I had to spend correcting and guiding.

Some engineers are just slow. I don't think it's much correlated with experience. If your goal was never to be a super productive programmer, I don't think you'll ever become one.

This might also be why there is this spectre of agism in the industry. Everyone knows there's greybeards out there that would eat your lunch and get paid the big bucks, but at the same time older programmers have hard times interviewing. At that age most of the really great programmers have probably already been fished out of the pond.


I think it depends... where I am now (third from last day), I'm one of the younger devs at 46yo. which is wild to me... about 2/4 of those here older than me have little interest in taking on new approaches or techniques. The other 1/4 absolutely work to stay current. Some are coasting to retirement, others of us don't ever plan to stop.

I will say, my recent stint of interviews over the past 6 weeks or so has been pretty painful. Everyone seems to be going through 6+ interview stages. The reality, even then, I'm not sure they're getting a great signal:noise outcome. Some of the tests are for things that will never be used for those jobs on any given day.

I do miss my 20's when an interview was maybe an hour and a half on an afternoon, and an offer shortly after.


It's crazy, I wonder if it actually works and they actually get a higher percentage of good coders. I just do a face to face, then a take home assignment, then another face to face where we discuss the take home, and then I immediately make the decision. I skip the take home if they've got impressive GitHub accounts or other clear public displays of skill.


The issue I seem to often see, for some reason, is that people who have a say in hiring often don't realize themselves that the great engineer did something quickly thanks to an insight, or, more generally speaking, thanks to being very good, or being able to turn the problem on its head, as opposed to pure brute force.

They often seem to have the idea that it's more or less grunt work. Yeah, if a truck will haul 10 tonnes in one go, you'll get the same time if you hire an army of people, each carrying 10 kg on their backs, give or take economies of scale.


There is a flip side to that as well I think. One 10x developer can be more productive than 10 developers, but often 10 10x developers cannot be as productive as 100 developers. Certain things just don't "scale out" with the sort of creative advantages that highly productive engineers use.


Overly complex code is more difficult to modify than elegant simple code. A 10x developer will produce simple elegant code. That is one reason why they are a 10x developer. Ten 10x developers will create a much more simple solution than 100 standard developers. Standard developers usually create a mess. That is what always happens, we have all seen it. So 10 10x will be much more productive than 100 standard developers.


Speed an accuracy are on different dimensions that are somewhat independent.

Another consideration is how much time we can afford for the solution to be wrong and need to be tweaked. For anything that has to work the first time, you want one (two, really) of your more sober and likely expensive engineers on the case, even if they aren't your fastest.

You may or may be able to replace your 10x engineer for this kind of work, but you're likely to be hamstrung by your interview processes.


I've worked with a few developers who are great - people who get bored of waiting so just build it themselves one evening whilst everybody's arguing over funding/recruiting the team we thought was needed.

Within a team, I think 'greatness' comes in all manner of different forms, all of which are needed. The person who holds the whole software model in their head, and can rattle off the precise changes required to implement a new feature. The person who has an encyclopedic knowledge of all the technologies, and often spotted sat next to another engineer helping them through an issue. The person who mid-way through implementation spots a flaw or an improvement that can be make to the process and comes back offering options for improvement. Of course it's great to have the person who comes back after 2 weeks having written more code than the rest put together - but.. well monoculture is always bad. Wouldn't want a team of them.


Oof, sadly this sounds like me... It's hard to delegate, and even harder to trust that it's done correctly. I know this will be my undoing someday, it also drives me insane because it puts extra pressure on myself...

Any suggestions? (Short of let people do it).


Start small and practice. Evaluate how people react to the task size and experiment from there. E.g. don't make someone annoyed by tasks way under their stature grow at the same rate as someone who struggles to deliver.

This goes for clarity, difficulty and size of the task. Don't make someone bad at filling the details do an unclear task. Don't make someone unskilled do a clear yet difficult task. Don't make someone with no track record work on a task for too many days without supervision. Etc.

Unfortunately, people not meeting standards you would will always be a thing unless you're leading people more skilled in the area of expertise. Which brings it's own set of issues.


Realize that others are at other points in their lives. That just because the code does not look the exact way you would write it does not mean it is not bad/wrong. There is always one more refactor to do. There is always more bug. Worry about what you can do. Help others when they need it (not when you want to, this is tricky to not become the knowitall guy).

Delegating is knowing that you need to let go and ingest the fact that they are there to help. Mistakes happen and will happen. But that is part of learning for you and them. If they are not learning that is a different issue. Do not worry about it. You will learn what you can put them on better. But once they learn something they can turn around and help you learn. They can take care of it and you do not have to worry. Delegation is trust. Learning to trust is learning to 'let go' and being open to being 'hurt'. But also being willing to forgive and forget.


I'm not a developer, so maybe not the best person to ask.

What seems to work is where areas of the product are assigned to specific teams - the overly-attached dev can at least see what's happening, provide guidance, without having to do the work, point to wiki that needs updating etc. Over time they'll build trust and can back away a bit.

What doesn't work is if work is given to a different team who just do their own thing and the 'parent dev' only finds what's happened to their baby on the commit/demo. Even if they've done a great job, it ruffles feathers.


Try another career. You'll never be successful in this one. Sorry its harsh but that's the way it is.

Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.


On the flipside, I've met "10x engineers" who always prioritized working on highly visible and strategic new features, and excelled at shipping them as fast as possible, even if it meant racking up massive technical debt. By doing this, they effectively did produce 10x as much in the eyes of management, and got promoted and rewarded in kind. The technical debt they racked up then got paid by everyone else that had to go in and make their prototype maintainable while they were already off to the next high-profile project. Not only did they not have to stay and cover the cheques they wrote, they also managed to lower the effectiveness of everyone else, lowering the baseline they got compared against, so they could be 10x instead of just 5x.


> On the flipside, I've met "10x engineers" who always prioritized working on highly visible and strategic new features, and excelled at shipping them as fast as possible, even if it meant racking up massive technical debt.

I start my comment with an intent to indicate that these people are not what is meant when people say 10x. (maybe it's what some people think of when lambasting "10x" developers).

If you think you're a 10x engineer: you're not, you wouldn't see yourself as better, you'd see yourself as passionate.


I have the opposite issue here. I have an engineer still writing VB6 code and we have 20 man years of his technical debt we have to live with. He never learned anything new and he has a hammer and everything is a nail.

As a >5x engineer I generally build out the initial design/development of a project and then hand it off to a team member to maintain. I get involved only when there is a new significant feature that needs to be added.


Though, the order of events might be backwards there sometimes. The director has a highly visible and strategic new feature they need executed, so they'll handpick the best engineers to work on the project. The engineers complete the project as fast as possible because that was the point of the project, to get the team that could produce a MVP fastest. And the technical debt and productionizing of the project is something that can be done by a less specialized pool of developers, who also are given way less tight time constraints.


Their value is in shipping fast.

If competitors are working on the same feature and manage to roll it out of the door first, that spells trouble.

First version of Twitter was an almost complete re-write because of performance issues. But since their concept was dead simple, they had to get market shares fast else someone else was going to be there first.


On the plus side, the company shipped something. In a startup time to market is important. Especially in a startup.


That’s right, the mythical 10x-er who does greenfield work, uses the latest tech, who not only never maintains their masterpieces but moves on to other pastures causing other devs loss of productivity and captive to their mazes..


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

It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.

Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly. That's not enough to kill them mind you, not right away anyway, so they are destined to be mediocre at best I suppose.


One of the hard lessons I've learned in software is that force of will can make any development or management process work for a little over 12 months before the cracks really start to show. By then people (and by people I mean folks who don't think the way I do) have cemented that process in their heads as working and they want to ignore the data that says it doesn't.

If you are up or out as a manager, then any changes you didn't make right at the beginning of your tenure are going to unravel under the watch of your replacement. You not only don't have to reflect on them, but lots of people nominate someone else as the person who needs to fix it/take the blame. If there's a better recipe for willful ignorance, I don't know what it is, and I'm pretty sure I wouldn't want to.


> It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.

Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others.

We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.


MapReduce. Leveraging lower level abstractions incipient in the early Google datacenter (distributed FS, distributed process executor) and providing a simple but expressive programming model for distributed large scale batch computations. A significant amount of effort went into documenting and exemplifying the usage of the programming model for a large number of use-cases. Chosen to serve thousands of use-cases all across a fast growing company. Developed by 2 people. A fantastic example of '10[00]x engineering', and yet I can't imagine something more antithetic to the 'lone gunman' strawman.


I think Jeff + Sanjay is arguably a better example of 100x developers. Goes way beyond just MapReduce.

Edit: I just noticed that you said the same yourself. Great minds...


A really good developer can and will absolutely outpace a couple small teams of developers. The shortcomings is the domain knowledge is locked in one head. You gain and lose a lot depending on how many people are involved and how much you have to communicate.

Not having a backup solution is probably the single biggest shortcoming of the lone gunman in practice. The second is that the code is often not laid out or structured so that a team can work on it.


As the MapReduce example shows, the domain knowledge is not necessarily locked in one head in cases like this. I haven't heard complaints from Googlers about how Jeff and Sanjay write unmaintainable code, either. My own non-Google experience is that extremely productive programmers tend to write code that's more readable, not less readable.


“Adding people to a late project makes it later”. Equally, replacing high performers with multiple people wouldn't work most of the time.


Are we sure they're not actually the exact same problem?

Hypothesis: the "10x" developer does not actually have 10x the output of a single average developer, but rather the same output as 10 average developers working together (and having much of their productivity eaten up by coordination overhead).


That is a good point... and gets back to the chief programmer of the MMM surgical team.

One of the aspects of having a chief programmer (and there's another HN article making the rounds on heroes for projects) is that they're able to conceptualize/structure/design an entire application or module.

A chief programmer, doing a "this is how we're doing it" and with all the parts in their head and working to that end will have better overall "idea to deploy" performance than someone who is given the task of "do X" and may have to come back to it again to reconcile their implementation of X with the design of the system and its goals.

The way to resolve that is to get everyone who is working on it on the same page for the design... and that takes meetings leading to the issues with adding more people to a project will make it later.


Yea funnily enough I just added a comment along these lines about restaurants in a different story. Just because an engineer is 10x better in some sense that another one, it doesn't meant that 10 of the lower quality engineers will make up for it, just as eating 10 times at McDonald's isn't going to be as much fun as eating once at a great restaurant (for most people)


I'm a good cook, but compared to Wolfgang Puck, I make shit on a shingle look brilliant. You could hire 100's of me and not get a decent restaurant. After so many decades as a programmer, there are enormous gaps between programmers in their ability to deliver quality. Calling something 10x is not a measurable quantity, but watching quality delivery over and over gives you the impression; the number is arbitrary.


But, I think, you should consider that it's 10x at McDonald's vs 1x at a good restaurant and 9 days eating nothing at all.


Yes, this is obviously just considering utility at a higher level of the hierarchy of needs, not pure subsistence. Otherwise everyone should just be slurping Soylent all the time I guess.


only if you think that any organization that hires a 10X engineer doesn't hire any 1X engineers.


More people means more human error, which means that not only do you have to invest more in communication overhead, but you have to invest more in sanity checks to keep your state machine in bounds.

The original author always knows not to push buttons in this order. Two people who are communicating badly will find a way to do so sooner or later, and if the system doesn't slap you on the wrist for doing so, it's gonna be a bad day.

On the plus side, systems with these sorts of guard rails are better opportunities for self-directed mid-level developers to pull themselves up to a senior role. One man bands are notoriously awful at affordances for discoverability.

I think I do better than most but any time I want to shed a responsibility I always have to first add more docs and a handful of extra exceptions and/or exception handlers to the code to make sure the new person doesn't immediately have a bad experience and toss it back to me. I call it sweetening the pot but others might use a different description.


Author here. There definitely are people, who perform better than others, even when the environment is not built to favor them and hinder others from performing well.

If we believe that the talent within a field follows the power law, as suggested by this study (http://www.hermanaguinis.com/PPsych2012.pdf) it means that only 20% people in the field are high-perfomers, and something like less than 5% exceptionally high performers. When you look it from the perspective of scaling an organization it means that getting these people to your company will be very hard. 80% of companies are hiring within the "average or below average" section. The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.

There was originally a section the article that tried to highlight "statistics", but I eventually left it out, because I did not find a good place for it:

"Statistically speaking, it is much easier to create a "10x engineer" by creating an organization, where most people perform poorly than actually hire and retain someone, who really is 10x better at software engineering than an average person."

In hindsight, I think there are a few things that could have been emphasized more, so the thrust of the blog post would have been clearer:

- The title could have been better frased around the topic.

- The context is companies that are growing fast and need to scale.

- You likely have a company full of close-to-average people.


”The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.”

Is there a source for this claim?

How likely are they to move exactly, and what motivates the non-movers to stay?


This is based on my limited personal experience observing the careers of people I know, whom I could consider somehow exceptionally good at their craft. I co-led the CTO team of software consultancy with 350+ devs. In that role it was pretty clear that it was really hard to compete on salary and how interesting projects experts could be offered.

Motivations differ based on what the person values. The top motivations I've experienced are:

- Money

- Following intrinsic motivation and being able to grow professionally

- Friendships and the feeling of belonging

- Stability and not taking any risks

The people in the last two categories tend to change jobs more slowly in my experience, but most still do it at some point.

I'm not aware of any reliable studies on the subject from the field of software engineering. If someone knows one, I would be more than interested in reading one.


I would probably consider consultancies very differently from product companies.

Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.

I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.

Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.


In my experience the difference between good consultancies and average product companies is not very big. On average I've seen consultancies being able to attract more technically curious and product-minded engineers. The exception are the product companies that are somehow special in the market (e.g. can offer a significantly better pay, or do something very interesting in terms of scale or technologies).

The dynamic you describe tends to get stronger, when consultancies grow. The voices & competence of the technical people becomes less important when it comes to the business and efficiencies in utilization and the company brand start to matter more. The consultancy I worked at was not an incumbent, but an underdog competing with the big players, so the actual execution mattered more, when trying to win bigger customers. Even in consultancies, there are operational effiencies you get from having competent people. Mainly from having less middle management & account managers.

However, there things are useful for the consultancy's business only to a limited extend. You only need to be slightly better than the average consultancy and you're OK. So there is a point, when you either need to be great at sales or thought-leadering, or a consultancy can no longer increase your salary or provide your with work you find interesting.


Interesting on that first point, that's not what i would have expected. So what are you seeing from these product-minded engineers that leads them to choose a consultancy over a product company?

For "underdog" consultancies, i've always felt that they win by

1) sending their A team where an incumbent would be sending in their C team. That would make sense, as the incumbent's A team is on a more important client, whereas this small client "is" the underdog's important client.

2) carving out niches and specialties. So you serve less clients and projects, but also build up a reputation. You kind of become an incumbent of sorts, just for that niche.


Both 1 & 2 are valid strategies for underdog consultancies. Consultancies that are very good at #2 may also have better ability to keep people, who are exceptionally good at some specific tech or domain, because they usually have higher rates and peers that are good at the same thing.

As for product-minded engineers, there is often more freedom at a smaller a consultancy than in (many) product companies. You can switch projects every 3-18 months, select a new technology you want to learn, have big ownership on the helping the customer building the product, etc. To some people this is ofc a downside and a lot depends on the kind of client/project you're working in. Much of this also is lost, when the consultancy starts taking on bigger projects with bigger clients that already have much of these things set in stone.


If a brittle piece of JS (with high support cost due to runtime errors) is replaced with a piece of Elm, the runtime errors are gone.

The one that made the decision to change it, and actually ported the code, easily wins the 10x badge when we consider the high support cost of that brittle piece of JS code in production.

> institutional knowledge is lost.

Exactly! Say a dev rewrote the brittle piece of JS to resilient JS, and did this REALLY fast. Great, you may have a 10x'er on your team! But in this case the knowledge is merely with one guy, he has the experience and discipline to write resilient JS: something rarely found in human beings. In this case the 10x'er may be a 10x coder, but not a 10x architect/techlead/CTO.

Hence I dont like to depend on human's experience and discipline, but prefer to fix it with Real Good Tech and Tooling(TM).


Someone who thinks all bugs will go away if the code is just rewritten in the hipster niche language de-jour, is probably a 0.1x developer. They may work hard but don't solve any real problems for the business and leave a mess to future maintainers who have to spend time debugging the forgotten hipster languages of yesteryear.

Do you think the developers who rewrote everything in Dart or CoffeeScript a few years ago were actual 10x productive for the business in the long run?


They specifically said runtime errors. Elm is designed in such a way that runtime errors do not occur. Obviously logic errors etc. are still possible.


So what happens if you divide by 0 in Elm?


For integer division, you get 0 as a result. For floats, it is the Infinity value used by standard implementations.

The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).


You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular.

Maybe time to study some of that "hipster stuff".

I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).


I'm not knocking Elm at all, I think it is a very interesting language.

I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away.

A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite.

If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.


It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.


No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug.

Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.

JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.

Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.

Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).

But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.

Bottom line: Converting runtime exceptions to logical errors is a very bad trade.

I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.

I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.


Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors may crop up, it’s a worthwhile trade to many people.


Runtime errors means errors which occurs at runtime as opposed to compile time. Logical errors are a subset of runtime errors. Se for example https://en.wikipedia.org/wiki/Runtime_(program_lifecycle_pha...

This is the common definition.

Defining runtime errors as just being exceptions is clearly absurd - that would mean languages like C or assembler cannot have runtime errors!


To be fair, the grandparent said 'runtime errors', not 'bugs'. And it is a stated goal of the Elm language that runtime exceptions thrown from the compiled Javascript should be impossible. As far as I know, they have succeeded in that goal.

How this relates to 10x or not I don't know - I'm not sure the discussion is a productive one without further context.

It might be that for some tasks, Elm really does provide a huge benefit in productivity. In that case, it's probably fair to call a developer that selects and uses the tool correctly a 10x developer - provided they are able to evolve the culture of their company so that others can take advantage of it.

For other tasks, or in other contexts, Elm might be a hinderance. If it's lacking an indispensable library, or if the company culture is not ready to accept it as a core language, it won't help anyone to rewrite in Elm.

As always, one of the key things that makes a good (even 10x) developer is the ability to select the right tool, and to wield it gracefully.


I'm sure Elm is a great language, but thinking it eliminates runtime errors is ridiculous. Of course it might eliminate exceptions, but exceptions are not errors, rather they are (sometimes) signals than an error have happened.


Yes, this only holds for some definition of errors. Run time program errors due to type mismatch, nulls and exceptions are non-existant.

Pretty cool!


The question is, why was these run time error not caught by unit tests? Probably because there wasn't any tests - which means the code likely have numerous logical errors. Static typing is great, but it will not prevent against logical errors. So without testing you will have bugs in any language you rewrite in.


This is wrong. Rewriting your code in Elm (or other niche language) doesn't make you a 10x developer.

Same way rewriting your code in Rust doesn't make you a 10x developer for removing memory safety issues.

A 10x more productive developer is more productive within an ecosystem against others who are also in that same ecosystem. It's not fair to compare a C developer to a Rust developer in terms of developer skill. But maybe productivity you could. Like how Python is more productive than C++ but you don't call the Python developer a 10x developer.


You did not get my comment. I wanted to say that in choosing lang+tooling is a great place to make the 10x difference.


Is it really that 10x performers exist, or that 0.4x performers are abundant so 2x performers look like 10x performers?

I guess what I'm asking is if there is any actual data on this so we can look at actual statistics or if it is all just a meaningless blogspam topic.


>Is it really that 10x performers exist, or that 0.4x performers are abundant so 2x performers look like 10x performers?

Performance is relative, so if the norm is 0.4x, that's the actual "1x" base to just 10x programmers by, even if it's below what a 0.4x programmer could potentially achieve if they really tried.

In other words, if most devs are underperforming due to complacency, lack of motivation, etc., that should also factor in in the 10x programmer calculation.

So, 10x doesn't have to be "10x as good when both are 100% motivated" just "10x as effective" is enough (even if it's because they are more motivated and not actually more intelligent, knowlegeable etc).


The norm can still be 1x and the number of 0.4x can apparently also be too abundant for comfort.

>There is also a significant variation in how the same person performs across multiple tasks.

Not only that, sometimes one individual can engineer things 10X better than at other times.

>Do these two engineers have the same experience with the technology at hand?

No, one has 10x the experience.

>How familiar are they with the system they're working on?

Very, one is just 10X more familiar.

>Do they have the same ability to make decisions on the go?

No, one is a 10X better decision maker.

>How easily can they get help?

Both easily, but one of the two only needs help 10X less often.


What I'm getting at is if our 1x is defined by average or median, essentially. Of course without actual data it is impossible to say.


Abstractly it's nice to know.

But practically does it really matter?

Even if we knew the case, one can't just e.g. whip 0.4x into 1x, so a 2x remains a very valuable 2/0.4 jump.


> Even if we knew the case, one can't just e.g. whip 0.4x into 1x, so a 2x remains a very valuable 2/0.4 jump.

This is pure speculation, which is why actual data would be useful. Is a measured 0.4x performer that way for innate reasons or is that something which some combination of training and mentoring, better tools, streamlined environments, etc. can help with? — or is the way that's measured even valid? I've seen a few cases where someone got flack for being slow until wider perspective showed that they were the only one solving the customer's real problem because it turned out that what they were doing was more complicated than it looked and/or the other guys were “solving” it in ways that required lots of ongoing maintenance.


>Is a measured 0.4x performer that way for innate reasons or is that something which some combination of training and mentoring, better tools, streamlined environments, etc. can help with?

For this or that individual (as per your example of "a few cases"), maybe.

For the majority do you think there will be something that hasn't been tried until now, what with all 2000 methodologies of management, team structure, company culture, development methodologies, tooling, agile, waterfall, and what have you, that will suddenly make a difference?


I think there are plenty of things which make a difference — for example the training and mentoring I mentioned — but the methodology point touches on the problem that they're neither cheap nor easy and most places are unwilling to invest in them. Very few companies which “adopt” something like Agile manage to substantially transform their culture because that's hard and it's a lot easier to make an announcement, do Agilefall, and avoid hard conversations.


Having worked at really high quality startups, and low-quality companies, this is a real thing.

0.1x developer might be a 10x developer that has given up because the build or management is fundamentally broken. Working more will just lead to burnout.

a 0.1x developer might be someone who at some point was very talented but now has no clue, but enough savvy to stay on as a lead/architect/senior

a 0.1x developer might not be qualified, but was hired because the company paid well below market rate.

Many reasons... A 10x is motivated, intelligent, and in the right place at the right time.


The Survey cited in Peopleware says that it is a 10x difference between the best and the worst performers. The best performers were something like 2.5x the average performer, as measured by time to complete a specific coding task in the 70s.

Office environment was a factor in performance.


Peopleware is 30 years old though. Back then very few decided to become programmers. Today when everyone flocks to the field chasing money and you have several orders of magnitude more programmers the ratio could be very different.


Don’t forget that we have -x performers.

There are some programmers who are worse than nothing happening. So a 10x looks better by working accords the averages of all the 1x, -1x, etc.


On the Net Negative Producing Programmer - https://wiki.c2.com/?NetNegativeProducingProgrammer and the referenced article from there http://pyxisinc.com/NNPP_Article.pdf

That article starts out with...

> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.

> Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]

Source 21 is: Shneiderman, Ben Software Psychology: Human Factors in Computer and Information Systems (Cambridge, MA: Winthrop, 1980)

https://www.amazon.com/Software-psychology-computer-informat...


Yeah, this is an important point when thinking about it from an organization perspective. I've been at places where they "only wanted to hire rockstars" which was beyond stupid. By definition 10x developers are rare and are going to have a lot of options when it comes to where they work. So if you depend on some member of the team carrying a hugely disproportionate amount of the work, then you are in for a rude awakening when they jump ship.


The problem I have is they always want me to train someone as insurance for if I leave. It becomes a self fulfilling prophecy when you make me work and train mediocre people. I just want to build great things and be left alone.


This blog post has some really interesting thoughts on that point: https://applieddivinitystudies.com/2020/10/15/bus-factor/


Yup. this is my life. I have a dev title but im really directing people. I don't enjoy doing both. May as well get paid accordingly.


This is something our industry needs to fix. I've turned down promotions so many times because they amounted to moving from coding to pastoral care. Which is bizarre - it's like a surgeon being offered a promotion to work in HR.

Many companies do have an individual contributor track, and that's a big factor in where I choose to work, but way too many companies seem to think it's all kinda the same thing.

(To be clear: none of this is neglecting the importance of, or talent involved in, managing people. Bringing out people's potential requires tremendous skill, which I don't have, and that's why I won't do it.)


If you trained one or more operators who have already left for alternative employment, you could point out that there may now be other orgs making more money from your technology than your own employer is.


>you depend on some member of the team carrying a hugely disproportionate amount of the work

This can be a problem when there is only one high-performer.

You hire all high-performers so this is not what happens.


I still haven't met any 10x engineers.

What I have met are 3x engineers who protect their own job security so severely that they make everyone else a third as effective.

3 * (1 / 1/3) = 9

Meanwhile I'm a 3x engineer who makes everyone else twice as effective. Management sees me as a 1.5x engineer, when my actual factor depends on how many coworkers I have.


You don't always have a choice: you cannot replace a person that can read with 10 people that cannot read. All of the very few "10x people" that I met had expertise far beyond their team mates had and they used it well.


People don't always leave, although they do die. Peter Norvig has been at Google since 02000. Jeff Dean has been at Google since 01999. Ken Thompson was at Bell Labs from 01966 to 02000, when he "retired" (but, really, Bell Labs no longer existed). Mick Jagger has been in the Rolling Stones since 01962. Marvin Minsky was at the AI Lab from its founding as Project MAC in 01963 until his death in 02016.

What would the Rolling Stones look like if someone had said, "Our organization shouldn't be resting on the shoulders of Mick Jagger"? What would Google look like if someone had said "Our organization shouldn't be resting on the shoulders of Jeff and Sanjay"? What would CSAIL look like if someone had said "Our organization shouldn't be resting on the shoulders of Minsky"? They'd look like mediocre failures.

"How are you going to replace Jagger if he quits the Stones?" is not really the right question. You have to accept that the Stones without Jagger, or Bell Labs without Thompson, just would not be the same. To a very great extent the productivity of a creative organization depends on its ability to attract and retain high performers, because it's inevitable that it rests on their shoulders. Denial won't change that.

If you want your organization to succeed in a creative field, the right question to ask is, "How can we hire people like Ken Thompson, and how can we keep them from wanting to leave?"


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

When I left my last job, part of what I was doing was replaced by a team that built up to 5 engineers last I checked. They're doing it more intensely (although, I don't think with better results), and they've got to have a lot more communication than when I did it (I was trusted to do cowboy deploys to an isolated system, they've got to deal with code reviews and just making each other aware of what they're doing because 5 people in a small system means overlapping work). And, I did a bunch of other stuff too which AFAIK didn't really get picked up, but hopefully they've been lucky and not had weird TLS problems or other 'select is broken' experiences lately.


My employer considers me a 10x developer. It's not a title I'd choose for myself. I'm the only software engineer to be on a bonus scheme, which is great.

But it means I'm expected to be available constantly. I'm not a one-man team but I tend to be the first point of contact for people outside our Eng team. It gets a bit much sometimes.


Make sure your enployer isn’t just stroking your ego to make you work long hours and take on more responsibility. Make sure you get the compensation you think you deserve not future promises..


> 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'd agree. I don't think the article is refutes that "10x engineers exist" - more that some engineers who are able to work fast are incorrectly labelled "10x"

i.e. Having more knowledge or banging out shonky code might let you appear more productive than your peers, and you should probably adopt more metrics than simply coding tasks getting completed.


Indeed! Did he get time to "share knowledge with his peers". Would he have been credited for it? Would his position in the corporation have gotten more secure?

In a U.S. corporation, the answer to all these questions is "no".


I strongly suspect those conditions are not confined to the US.


This here. I think the author is confusing what a 10x developer is.

I took the 10x dev to mean somebody who may work efficiently but also improves all of the devs around them. Improving yourself by 2x is one thing but improving the team around you by 2x is where you get the 10x.


> the author is confusing what a 10x developer is.

Its a subjective definition. You have a different one to the author. sneak has a different definition to you.

That's a part of the problem: there's no clear definition and the label "10x developer" means different things to different things.

Some of these definitions definitely are a myth. Some are not. But the conversations about it tend to not be that meaningful, because everyone argues their own definition, which may or may not match up with other people who are also arguing theirs. The best we can do is define our definition and then state our reasoning about it and then others can agree or disagree or say yes but if you define it this way that I do, then its different because whatever.

Right now, everyone has a different definition and the discussion isn't that useful.


My coworker is a beast at churning out working code, but mine is often better abstracted and requires less refactoring to use in the future.

There are features where I spent 5-10x the time he'd do, but my code could then be used to later implement several dozen feature requests in mere minutes rather than hours and days.

Who's better? I'd say we've got different strengths, so depends on what you need to get done.


Your coworker is better, sounds like you spend a lot of time on premature generalisation.


Technically premature yes.

But I do have experience guiding me. It's not like I'm abstracting everything I do. So my efforts tend to pay off.


No, the 10x developer is someone who, alone in a room, can ship in y period of time the same thing it would take 10 median developers y units of time to ship, or one median developer 10y units of time to ship.

Because of the mythical man month, the 10 will actually take >y time to do it, due to coordination overhead. The 10xer will still ship the item in 1y. A big part of the leap from 5x to 10x is being able to dodge communication overhead.

Some are also good at boosting their team. Some only work well alone.


Yeah, this reads like a straw man attack on a particular and not widely accepted view of what a 10x engineer is.


Yeah, great programmers are also great documenters and also process-oriented and detailed

Dennis Ritchie, Vitalik Buterin, Jeff Dean exist


The author is talking about people who are perceived by management to be 10x developers and why that perception can sometimes be flawed.


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.


Perhaps best is when they make other people more productive by pointing them in the right direction early on. Everybody has been stuck on a problem for days or more. Someone who can get you moving again by asking the right questions or pointing to an alternative approach can make you a lot more productive.


> they select a path to the solution that is a lot shorter.

Yeah, I've also seen this. A lot. And selecting a shorter path often includes redefining the problem to be solved.

In fact, as far as I can tell these kinds of differences are the norm, not the exception.

From the article:

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

This is almost certainly true, but completely misses the point. The point of 10x engineers is that they change the environment. They don't type in code 10x faster. If you don't allow them to change the environment, they won't be 10x more effective.


I'd add that its also in the design of things and deciding what to work on.

I've seen small design decisions lead to a lot more (or less) work for the whole team. I've also seen teams work for months on things that didn't need to be done.


I'm mid-career, I guess, and these days I kinda feel like I've fucked up if I'm writing any serious amount of code, under most circumstances. The best solution is often a small script in the right place, leveraging existing software (when the best solution isn't "FFS, just pay a SaaS to take care of this, it's not even worth the time we've spent talking about it"). When I'm writing an actual project, I've got this nagging feeling like I just didn't know enough to avoid writing it. Like maybe I need to go RTFMs of the many battle-hardened daemons and OS components I have available and could be using.

Any time I do achieve "10x" versus anyone else (and I think I sometimes do, though the broad "anyone else" makes that less impressive) it's usually because of what I didn't write.


The smaller a Pull Request I submit, the prouder I am of it.


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

I know a developer who likes portraying himself as a kind of 10x.

He does not code faster, better, or smarter. His talent is managing his supervisor's expectations. He massages management to revise goals and shave off requirements, he is able to leverage even the smallest bump on the project management road to remove requirements and justify delays, and in the process he is able to put together a MVP that meets a fraction of the initial requirements and in spite of barely working does meet his manager's acceptance bar.

In the end all that is left is the story where he single-handedly delivered a working product, he moves onward to greener pastures, and an unwitting team is left with the architectural problems, myriads of bugs, missing features, and the blame for stuff failing to work in production.


I think you are just salty. Communication is really important and seems like that dev was really capable at it


> I think you are just salty. Communication is really important and seems like that dev was really capable at it

I'm not sure you got the point. The whole point is that, exactly like OP stated, some of these self-described 10x developers do not code faster/better/stronger at all. They might even suck at it. However, they do excel at all the salesmanship required to descope critical features out of a project until all it's left is a fraction of the original project, and also excel at managing the expectations of all stakeholders so that the 1/10th of the project they deliver is passed off as the desired outcome.

Once they succeed at turning a production project that requires a team to write into what amounts to a proof of concept that's doable by a one-man team, they find themselves in a position where a person alone can put it together.

To put it differently, it's easy to run a whole marathon at 1/10th of the time when you succeed at moving the finishing line to 1/10th of the marathon's length. That requires skills, but they are soft skills and not hard skills, and you do not need to run faster than anyone else to do it.


Writing code is the simplest thing in our job, once the problem and goal are clear the solution presents itself.

Knowing what to write, what not, how to solve users problems and how to understand users problems in the first place so you know you're solving the right one up to users expectation, that is the hard part.

A testing methodology that moves from programming kohans only tests the writing code part. Of course you find low variation there!


Why not both? There's at least a factor of 3x difference between the volume of the most prolific programmers I know and the least. If John Carmack ships the product in 1/10th the time of Average Joe, I would call him a 10x engineer regardless of whether he picked a smarter design or if he simply implemented the dumb design 10x faster (or anything in between, obviously).


This is finally what allowed me to overcome my own self-doubt.

I'm not the fastest programmer and I don't have the most intellectual horsepower either. What I do have is an enormous body of knowledge built up over many many years that allows me to select the shortest path or atleast guide people smarter than me into the right area of the solution space where it should exist.


Unfortunately in big companies, pointing in the right direction isn't good enough: then you have to fight inertia, inter-team, inter-site disputes to finally do the right things :-(


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.


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

This is, at best, half true. The high performers might get the most attention from certain teachers (esp. in middle class and upper middle class schools), but systemically they are ignored.

1. The general idea in education circles is that the higher performers “will do fine” without any additional attention, so they don’t need much help. As such, very little research attention is focused on them.

2. Gifted education is a joke in the US. Almost completely ignored.

3. Most honors classes are also a joke in that they are often regular classes with more busy work.

4. AP classes are sometimes good, but it’s often easier just to take an actual college course if your school allows it. Same or less classroom time and much less busy work.

5. School administrators are evaluated based on performance metrics. In almost all cases it is more beneficial and often easier to improve the low performers than it is to improve the high performers. This is largely due to the metrics that have been chosen for evaluation.

As for Japan, that observation is very true. That said, most of the talent mismatches disappear starting at high school and sometimes junior high school due to tracking (of which I am a fan).


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

That's very interesting. This is anecdotally very contrary to my experience in middle-class public school, and my sister's experience as a teacher in a lower-income school.

Was the doc shot pre-NCLB? Is it simply a matter of variance across a large country, and my viewpoint is biased?


I don't remember. It was a long time ago. In my experience, this is exactly what happened, in my schools (I attended US public and private schools, after 5th grade).

I saw it from both perspectives. I was very smart, and did well, when I applied myself. I could also be a nightmare slacker.


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 don't think anyone really doubts that some engineers will work an order of magnitude or more faster than others on a given task. They just think it's a misleading way to think about performance, which likely falls on a unimodal curve within your organisation, and likely differs by task.

How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x? The premise gives the impression that you can neatly split engineers into two groups, which is wrong. Your 500x engineers are only going to perform that way on tasks they've done before, your 0.2x engineer might just have the flu or might be an intern on his first day, your 2x engineer who wrote a parser for that weird proprietary format last week could be 0.5x this week because she's working on ansible scripts, and in general it's impossible to settle on a constant integer factor of engineering ability that does any better than IQ.


You're looking at a very different kind of Nx engineer. The kind I'm talking about is where they approach a brand new problem that no one has an idea how to decompose using any tech that they have a clue how to operate, then a concise solution somehow appears using mostly what is already in service with careful splitting of tasks that appear clear and obvious only in retrospect. It's not about volume of output, precisely the opposite.


The original studies that gave us the concept of a 10x engineer tracked defect rate and speed on programming tasks. You're using your own definition of an Nx engineer that:

- does not relate to speed or defect rate

- does not provide any way to quantify what N is

- does not explain how an Nx engineer differs from a normal competent engineer

There's no problem with saying "engineers who can solve novel open-ended problems exist", the problem is that there's no reason to call those engineers 10x, no reason to suggest ability to solve those problems is a yes/no question, and no link to the original studies that we got the concept of a 10x engineer from. I remain unconvinced that the concept of 10x engineers is very useful.


The difference isn't only in how fast/well tasks get done, but a very good engineer will make many such tasks unnecessary altogether with better design and implementations that forego their need. Without including this aspect, the metric is a low-level one and not indicative of overall impact.


That's the point. If you don't have a metric that says "Alice is 10x better than Bob" and you don't specify a task she's better at, then what you really mean is "Alice is on average and by some unknown factor much better than Bob on the tasks she performs".

Framing it as though you have a rigorous comparison between them will mislead you into thinking about engineers as if they were fungible, like diesel generators, which is a very silly way to think about a divide-and-conquer field like software engineering where engineers develop different levels of expertise in different things.

If you're suggesting there is some underlying factor, like generalised intelligence, I'm not arguing with that! I strongly disagree that factor has anything to do with the number 10, or that engineers fall into discrete 1x and 10x camps, though. I think the phrase "10x engineer" leads to logical fallacies about performance.


I don't see where we disagree at all. I suggested 100x and at the same time didn't try to measure or spec it in any concrete way, which seems meaningless but have had enough interactions to say it has merit. I have no interest in why, unless it's something I can use to hire or train.


> How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x?

This is the hard part, isn’t it. It’s hard to tell beforehand, but if you’re skilled enough you can look at someone’s contribution history and see what they’ve done over the past years. It’s not perfect, but it helps.

Similar to how you review a 10x artist, just look at their work.

I don’t think asking people if they are great is very useful.


Agreed. They absolutely exist and I think 10x is too small of a multiplier for what they can do for a project and team. In particular, starting a significant project from zero often requires them.

We’re fooling ourselves that they don’t exist and, if they do exist, are universally toxic.


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.


==An engineer who could have solved this problem without a fuss within a month or two is easily a 10x engineer.==

They also need the trust of their superiors to be listened to in the first place. A 10x engineer isn’t helpful if management doesn’t take their advice.


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.


I think this is true for any group of engineers - some will be much more productive than others. That isn't because those engineers are better, or "10x" though, it's simply because they're working on a problem they find interesting in an environment where they're thriving. The less productive people aren't enjoying the problem they're solving, or there's something about the company or team that isn't right for them.

Most capable engineers have the potential to be "10x engineers" compared to their peers if they find a problem they're passionate about in a company that works well for them.

The real unicorn engineers are the ones who are able to drop in to any team and be like that.


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.


People often forget that 10X does not (only) mean quantity, but most of all quality.

Also thinking in factors may not be the right approach here. We should look at it in a more binary way: Can a developer achieve the requirements or not? In most cases the magnitude of skill shows in what a developer can solve at all, not how fast he/she can solve it.


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 ]


As much as I admire Peopleware, I think on this it misses the fact that there are "negative"-X programmers. Adding them to a team means the team gets _less_ work done, either through endless questions, dodging responsibility, demotivating others etc. In this kind of best/worst metric you end up with above-infinite-X programmers, because the worst you could give a working system to and they will break it.

Once you filter out the worst, I've still seen 10x-vs-median programmers. They have some insight which collapses a buggy, never-complete 50kloc library into a 50 line function plus a call to a SAT solver, or have some deep understanding of the underlying system that lets the whole team avoid spinning its wheels on an impossible-to-diagnose bug. These people are worth 10 ticket-closers any day of the week.


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.


I'd also qualify it by saying that a 10x engineer is not a 10x engineer for long if you burn them out or even if life just happens.

I've met a lot of spunky young college grads/drop-outs who felt like 10x engineers but had no family, no hobbies outside programming and no social life outside meetups, conferences and work.

I've also met people I'd confidently describe as 10x engineers who had all of that but in turn spent far fewer "productive" hours at work than the former.

There's a common misconception that you need to find "young talent" and make them work maximum productive hours (who needs to do chores when you have a work-provided luxury cafeteria and laundry service?) to get the most value out of them like they're top athletes. Well, most top athletes retire before they hit 40. If that's your plan, you're not looking for 10x developers, you're just looking for more meat for the grinder.


This. Very much this.

I've probably fallen into the "10x" camp myself at certain points in my career, and it was absolutely due to these factors. I should also add that having a general expertise of the problem domain and environment are enormous boosters as well.

Of course the moment I'm considered "fungible" and moved to a project I'm not passionate about at all, I'm pretty sure this evaporates entirely.


Yep. I've seen 10x engineers become -1x when shoved into projects they hated. Their contribution became net negative to the project.

And then return to 10x when transferred back to projects they enjoyed.


But there's so much work that just has to be done, whether anyone loves it or not. For that, I think reliable mediocrity is a fine objective.


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.


More broadly, the 10x engineer makes sure there are no such minefields.

They make sure there are nearly zero hurdles to getting in the zone.


Ah, no, quite the contrary.

The person who makes sure there are no such minefields makes a lot less great advances him/herself - they're busy working in a careful, orderly and considerate manner. And then the other engineers perform close to his/her level. That's not the 10x engineer.

However, the person who lays the minefield may only be a 1x person talent-wise, but since he puts his colleagues on 0.1x, s/he is effectively the 10x engineer of that team.


If people can perform so much despite the minefields, then these are not minefields.

If we agree that they are minefields that impede programmer's performance, then by definition someone who does not make sure these mines are never introduced in the first place will outperform those who just leave them all over the place.

> they're busy working in a careful, orderly and considerate manner.

Actually no. It only takes very little initial effort. He spends most of his time producing actual work.

Meanwhile, other people spend a considerable amount of their time fighting against bad tools and bad development environments.

Worse, they might not spend a whole lot of "total" time fighting against the minefields, but their presence ensures they can never get in the zone (flow) and thus they always perform worse than their potential.


Almost by definition, the 10x engineer is the one who is in a position to reuse and work within his own code, almost exclusively, rather than navigate the minefields laid by others.

The 1x engineer is a normal one who builds upon the work of other 1x people.

The 0.1x engineer is the one who builds upon the 10x engineer's work.


Seems more like time pressure than incompetence to me.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: