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).
> 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.
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.
> 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.
> 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.
> 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.
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.
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.
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.
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).
> 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.
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".
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
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....
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...
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 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.
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.
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.
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.
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...
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.
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.
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.
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).
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)
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?
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?
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.
>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).
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.
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.
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".
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.
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.
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.
> 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.
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!
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.
> 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.
Readit News
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.
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.
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).
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
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.
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.
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.
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.
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 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.
It absolutely does, just look at surgeons.
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.
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.
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?
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).
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.
"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.
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.
Deleted Comment
Dead Comment
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".
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
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....
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.
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.
Most people who run cannot even complete a marathon. Then there are ultramarathons.
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.
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.
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.
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.
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.
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.
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.
Any suggestions? (Short of let people do it).
Deleted Comment
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.
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.
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.
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.
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.
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.
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).
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.
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.
Is there a source for this claim?
How likely are they to move exactly, and what motivates the non-movers to stay?
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).
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?
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.
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.
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).
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.
Office environment was a factor in performance.
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.
This can be a problem when there is only one high-performer.
You hire all high-performers so this is not what happens.
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.
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?"
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.
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.
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.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.
In a U.S. corporation, the answer to all these questions is "no".
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.
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.
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.
Dennis Ritchie, Vitalik Buterin, Jeff Dean exist
It's not that they write code faster. It's that 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'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.
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.
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.
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!
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.
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 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.
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).
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 saw it from both perspectives. I was very smart, and did well, when I applied myself. I could also be a nightmare slacker.
Sus are those who write to debunk it.
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.
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.
We’re fooling ourselves that they don’t exist and, if they do exist, are universally toxic.
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.
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.