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
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.
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.
In any case, this Wikipedia article  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.
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.
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 honestly don't understand how this is relevant.
Carmack is 10x in coding and designing software. Jobs was 10x in PR and persuasion.
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.
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.
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.
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.
Not sure that's a bug.
Seems no matter what Jobs thought, Carmack kept bringing value and shipping great software.
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.
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?
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.
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.
And if my "problem" is not having heard of Buterin and Dean, I reckon myself a fortunate fellow - I can think of worse problems.
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.
Because of diminishing returns, improvement can still be seen as potentially some kind of multiple in many skillsets.
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.
(That link has a video of people on a giant treadmill, moving at Kipchogi's world record pace, trying to keep up).
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.
"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.
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.e. Your regular professional career developer who does good solid work and is always rated "Meets all expectations". That's the 1x.
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.
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.
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".
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.
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.
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.
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.
Well, your idea is probably closer to the Marilyn Strathern definition.
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.
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.
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.
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.
and then there's Mauro Prosperi
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
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)
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.
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 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.
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.
central theme is that "adding manpower to a late software project makes it later."
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 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.
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).
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.
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.
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.
Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.
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.
Edit: I just noticed that you said the same yourself. Great minds...
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.
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).
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.
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?
Motivations differ based on what the person values. The top motivations I've experienced are:
- 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.
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.
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.
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.
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.
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?
The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).
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).
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.
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.
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.
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.
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!
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.
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).
>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.
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.
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.
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?
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.
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)
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.)
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.
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.
But I do have experience guiding me. It's not like I'm abstracting everything I do. So my efforts tend to pay off.
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.
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.
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.
- 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.
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.
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.
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.
- 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.
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.
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.
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.
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.
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 ]
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.
Or to put it in a different way: "In the land of blind, the one-eyed is a king".
If you want a 10x engineer, give them work they love.
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.
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.
And then return to 10x when transferred back to projects they enjoyed.
* 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.
They make sure there are nearly zero hurdles to getting in the zone.
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 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.
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.