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.
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).
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.
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.
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
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.
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.
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.
I know that I've had many colleagues that were next to useless - even, possibly, exhibiting negative utility. Let's just give that kind a zero. Then there are novices - smart people with little experience. They can get stuff done, but they need watching. Suppose we give those a 1. And suppose we give an "average" dev, fairly smart, with a lot of experience, a 2. Such a person doesn't need watching, and gets stuff done.
I'd say a zero needs to find more suitable work.
A 1 is worth investing in.
A 2 is most good professional devs.
So what's this x10 fellow? Well, I rate myself as a 2. I'm a journeyman, and I'll never be a master. But the people I've met that I'd rate as "masters" were no more than twice as productive as I was.
I can't imagine a dev that was 10x as productive as a journeyman. I've certainly never met one. Software development is a process of discovering and remedying bugs - from the requirements, through the design, to the implementation. These things take roughly the same amount of time, whether you are a journeyman or a "master". And once you have identified the problem, the solution is usually fairly obvious.
If this notion of a 10x dev is a real thing, then I suspect it arises in people who regard technology as some kind of woo. If you're recruiting a magician, then he'd better be better than any other magician, because you don't know magic.
The fastest developers are those who barely put in bugs in the first place not those who are good at finding the bugs they themselves put in.
Example: Two developers writes half of a project. Developer A's code has 10 bugs, developer B's code has 1 bug. They both work together to fix the bugs, developer A fixed 4 of A's bugs while B fixed 6 of A's bug and his own bug. In total A fixed 4 and B fixed 7. In this case it looks like B was almost twice as effective, but if B didn't have to fix A's bugs he would have been way faster, especially since fixing others bugs is way harder than fixing your own.
Score your zero up slightly to 0.2 and a 10x is now a 2.
It’s not so drastic a claim really. The common misinterpretation is that it’s 10x the average.
* 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.
Recently in the discussions here, people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero. This is not what 10x engineer means. Please find another label for that phenomenon, for example 10x faker.
The failure of a software project begins at the contract stage. This gives salespeople a measure of control over the developers, and it is in their interests to increase developer stress by selling more things cheaper.
The worst part is that salespeople are prone to corruption: if they can make a client company pay less for a service, the company may hand over a part of their savings. This is difficult to control, as the kickbacks may come in material or immaterial forms.
The effects of the corruption are very real to the organisation, which now puts undue stress on developers with projects that are designed to fail just enough to trigger contractual clauses in benefit of the buyer.
I agree, but as you say, this is more often than not the definition used (unconsciously) by management. Management considers this person the 10x and others consider them the -1x.
And yet.. these developers are also great though, in their niche. It's awesome to have someone on the team who can whip up the demoware in an evening for investors and customers! Even when I'd rather they never commit anything to the product source.
Which is why this discussion of finding who is the 10x is misguided. Turns out people excel at different things. Good management will identify what everyone is best at and have them focused on that. Bad management will shoehorn people into the wrong roles and set them up for failure.
I don't think it's just about problem solving, as in "solving a math problem". The 10x is, I believe, the combination of different factors:
- Knowing you language and its ecosystem by heart: 2X
- Knowing your codebase by heart: 2X
- Mastering your tools (IDE/editor, Git,...), perhaps making your own tools: 2X
- Using good development methodology (e.g. limit trial-and-error or do it thoughtfully): 2X
- Being unsocial so people think twice before interrupting you: 1.5X
So in my opinion, on the contrary being a 10X engineer has a lot to do with being a good programmer.
conversely, company politics can be a reason why someone could be 10x in one setup and a complete dud in another.
It's just less socially acceptable to say it out loud, doesn't make it any less true. If anything, 10 is a conservative estimation: the spectrum spans orders of magnitude.
> a better focus would be growing the team as a whole
Not mutually exclusive. Prima donna behavior is always inexcusable. If you can't work with others you're not 10x, you're 0x.
Yeah, I've never seen it outside the SF bubble.
Where everyone seems to think they are the 10x, and everyone around them is a dolt.
He says 10xers exist, but they are bad for the company.
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.
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.
Every organisational silo has,in the long term, exactly one 10x engineer, a.k.a hero.
If there is no hero, the organisational silo will fail unless someone cares enough to take the role. If there is a hero, the need for a second one disappears. If a hero falls away, you'll have a few months of chaos after which a new hero appears.
People will naturally give problems and hard projects to the best available person, and generally people agree who that us. So one person with a slight edge gets all the training and quickly gets much better.
Heros are a consequence of organizational barriers.
Update: That last part is inexact. Heros are a consequence of knowledge barriers.
Or organizational barriers are a consequence of heros?
I've had the pleasure of working with two 10x engineers. One of them is a problem-solving and execution machine. I could understand what he did, and I think that I could have done the same, only taking 10x longer.
The other one... the other one isn't just a "faster me". His brain works on a qualitatively different way than mine. I probably couldn't have come up with the things he came up with, even with 10x or 100x more time.
These guys are also incredibly humble and nice, and hilariously funny. Fantastic humans all around. Stu, Matt, I miss you guys!
Or they are working in a small and well-funded company that only employs ~10x engineers, and they have never met a (to them) 0.1x engineer.
https://en.wikipedia.org/wiki/List_of_multiple_births#Nonupl...
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.
- What is a 10x programmer (what do they do better?)
- What is the impact of their presence (or absence) on a company
A 10x programmer is not someone who completes a narrowly defined task at 10x the speed of another engineer.
> In a controlled environment, the variation between most software engineers is much more modest.
Of course!
If you ask people to implement a small component as part of a large architecture that was already decided .. you won't find much of a difference in performance (unless you have people who are truly and utterly incompetent).
The excellent engineers would come up with a different design to begin with, but you can't measure that in a controlled study.
Now, knowing that 10x engineers exist, how can you use that to your advantage if you're a manager of a company?
If you yourself are not an excellent programmer, you can't just hire excellent programmers and hope they improve your business.
You will be fighting with them over control.
The key is to have excellent programmers in powerful position where they can call the shots about how to hire and manage and reward people.
If you are willing to give them that kind of power, then you have no business reading articles like this on the internet.
If you are not yourself an excellent engineer and are not willing to share power with excellent engineers, then no amount of reading of such articles on the internet will help you make the right decisions.
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.
Or to put it in a different way: "In the land of blind, the one-eyed is a king".
I was part of a team a few years back where I was certainly not a 10x dev. It was a team of... around 8-9 folks. 5-6 devs, PM, testers. There were jr/sr divides, but it was relatively smooth. My 20+ years of experience were helpful, but I wasn't 10x more productive than some of the lesser experienced folks on the team, and given the constraints and role I was in, there really wasn't a way to achieve that.
I've been on other projects where the experience level and other factors really exacerbate differences, and I've absolutely been "10x" in comparison to the others on the project.
The larger problems may come in with how you're treated, how you're viewed by management, etc.
"In a controlled environment, the variation between most software engineers is much more modest."
Well yes, but we don't usually work in controlled environments. With similar backgrounds/experiences, and strict project management controls in place, there's going to be far less variance possible.
The measurement is value in $, which easily can be translated to 10x-1000x better.
"10x" is obviously a buzzword and not a literal measurement, but is there any real doubt that productivity differences exist? Or is is just fashionable to not admit this anymore?
And for a few years I had it well measured because I was working with the same app and I was estimating all the tasks for me and the others with high precision to my own performance. The manager understood that other team members wouldn't follow my pace since they were less familiar with the app, and it was OK for him to estimate 2x or 3x the time when planning. But at the end it showed that I was average 8x faster (and with better quality) which was not justified since they were also senior even they knew the app a bit less.
The worst part is that I was earning much less than them due to location... but at least I could justify a request for a 15% raise which was given with no hesitation.
Set some real world useful target. Give the task to individuals or small teams and let them go at it, with regular followup. Measure time, defects, maintainability, whatnot. Perhaps add some real world change of requirements mid stream? I've seen solutions ranging from hours to never.
What I see, and find very sad, is that most organisations have obstinately obtuse attitudes and handling of such simple analysis.
It doesn't matter if the variance stems from intelligence, creativity, work pattern, experience, clever tricks, tools, processes, etc, etc. If it's faster/better then find out why, and learn from it. Can it be taught to others? Change work processes? Hire differently? ???
Whatever works. But ffs: measure, analyse, learn, embrace.
First, this is neither an exact science nor a multiplier (in this case, 10-times). I like to believe I have worked with a few of these "10x Engineers". I'm lucky to be technical enough not to be bullshitted by engineers and OK enough to sell to CTOs.
Here is my understanding.
They are not the ones who would produce XX times over a given period. It is not like normal/average engineers create X in 10 months; then they will do the same 10X in that same ten months or take 1-month to do it.
The pattern I see is that the work of these engineers lasts a very long time and stays relevant for quite a long time. Everyone who works with them is happy because they learn a lot from the actions or are predictable.
For instance, the QA team does not find apparent bugs or rare, most use cases, and the usual flow of actions and results happens.
I believe the 10X comes at a much later stage, over time, when the work is a rock-solid framework and foundation that everyone else can pick it up and work upon it.
I know I'm not very concrete, and I have to work harder to describe them in better ways. For now, it is more of a feeling I have after working with them. My only role was to understand them (not the technology) and shield them or cushion them from the BS-es that flow around anything that happens in a project/company.
We used to nod and agree on these lines -- So, what are our BS-es that we need to tell the management/client to cross this hurdle. But remember, we still need to make that BS happen.
Let me extrapolate the last part. So, I will huddle up the CxO of top Companies over a room, with concierge services waiting around to serve snacks, water, etc., but they won't be allowed to leave for a long time. Their phones are out of reach. When the other CxOs or executives are doing it, everyone else follows. I will throw around words like empathy; the design is subjective, iterative design, human framework, and all the jazz that pops up in my head. "The customer has to be able to find the shortest, simplest route to checkout."
Then I will meet up with the team, explain what I promised, and we will, kinda, laugh and wink. However, we will now convert those "Design is Subjective" to Objective Deliverable Goals and Binary answers -- YES or NO -- does this work or not - when that checkout happens, what steps, fallbacks, errors, and everything.
Companies eventually save a lot of money, as there aren't multiple iterations or griding other engineers 10-times.
This is a silly comparison. The engineers I've worked with in my career that stand out don't stand out because they can write for-loops faster than others or public-class-Foo-public-static-void-main-string-args-System.out.println-hello faster than others. They are much more productive because they are better at ensuring they understand the problems they're trying to solve, and solving the problem with the least amount of superfluous work.
> No one talked about the fact that this particular developer had been developing the same system for the past 15 years, the first five almost alone. He relished being “the best." Wrote hard-to-understand procedural code to 5000-line files. Did not actively share knowledge with his peers. Over the years, some capable developers had joined the company. Most of them decided to move on. The ones left were happy to coast along and leave all the heroics to the “10x engineer.” As a result, the company had great difficulties in trying to scale its development efforts.
This example seems like a counter-example to me. It's important to separate out one's (potentially flawed) judgement vs the actual value an engineer brings. This engineer made everyone else less productive. Simply calling someone a "10x engineer" does not make it so.
> The best strategy for most companies is not a relentless focus on trying to hire “the best” in hopes of finding 10x unicorn engineers.
The rest of the article is a distraction from this generally good piece of advice. For many things, finding a competent programmer familiar with your tools and stack who can write the CRUD operations you need should be acceptable. A lot of software engineering interviewing distracts from this, with gotcha trivia questions about whether one can recite from memory algorithms from a text book that are not relevant to the work.
Implicitly, he invites readers to re-evaluate their experiences.
To me, this rings true for most mundane organizations (not id software).
Bad/clickbait title?
Some people seem really uncomfortable with the idea that individual performance can vary massively from person to person.
In my experience, it is quite the opposite: while very few of the 10x engineer are indeed "leave me alone to solve hard problems; figure out yourself how to maintain my solutions within the enterprise", the majority makes simple, robust designs that are easier, not harder for the team to understand and maintain. And when they leave, they generally leave behind a system that is stable and does not need day-to-day meddling from a senior engineer, which gives enough time to find a replacement. My 2c.
Organizations with poor technical leadership fail to quality control hires and accumulate imposters. In this setting the lucky hire of a merely average developer creates the appearance of a 10x (or 100x) unicorn.
I have a feeling the writing has never worked with 10x developers. You know, everyone knows, that there's a galactic difference between the average team member vs that 10x in the corner crafting code like an artist chiseling into a block of marble.
... and then there's that awe inspiring, humbling privilege when you score getting onto a team where everyone are 10x-er.
The variation between most software engineers isn't modest, it's a Mariana Trench of a difference.
I saw for myself - there were places in my career where I was super productive, and places where I hardly produced anything. It had everything to do with the environment: politics, communication style, teammates, technology, and problem domain.
This entire discussion is deep in pointy-haired boss territory. First of all, creation and derivation of value from software is not "a controlled environment". Attempting to define things such that you can measure them means that whatever individual strengths and abilities people have will be washed out along with whatever advantages they could confer to the organization. As much as management wants to commodify programmers and treat it as an assembly line, programming remains a craft. It's not construction to a blueprint, but rather architect, engineer and builder all rolled into one—and the output is data and UI interactions with abstract purposes and mental models, not physical buildings with very straightforward goals and constraints.
The truth of the 10x engineer (or 100x or 1000x) is not that they code the same thing faster, it's that they find a better path. There are many different archetypes of this, you can't measure it, and you certainly can't hire for it, but with experience you can definitely see the impact of the smarter abstraction, the better anticipation of future requirements, the judicious application of YAGNI.
As an engineering manager the size of what you can accomplish is limited primarily by how you structure the team and give everyone the opportunity to play to their strengths. It's not about adding process and bureaucracy to ensure everyone feels equal, it's about setting up shared goals and fostering a sense of camaradarie so that natural leadership can emerge and everyone can do their best work.
I even expect that some consulting firms to this on purpose, at least if they sell services to customers that are put off by paying according to the value generated by the best developers, they bundle the best developers with teams of low-paid underachievers, where the lead is 10x as productive as those, and where the total output still matches customer expectations. Instead of paying $1000/h for one person they pay $1500/h for a team of 10 people, even if that one person could have more or less done everything on his own.
Which, I believe, is not to say you can't have that many people working in IT, but a major shift of thinking is required. Software shouldn't be a product, and I'd go even further to say that it shouldn't even be a deeply centralized service. Rather, a lot of IT pros helping smaller individuals solve problems (and just happen to use software while doing it, in the way that e.g. astronomers happen to use math) would be best.
Hint: What does Ari-Pekka do for a living?
Most people want to believe that what they do is the unique secret sauce of value creation, and they want others to believe it too. This is basically what you call politics.
Case in point. I have similar years of experience as Linus Torvalds and feel I am pretty good SE, but I couldn't have written git. Because his understanding is in a different level. I am able to understand how git works, but he was able to come up with the concept. I was happily using subversion but he knew what needed to be different and how to implement it. It is just another level.
The question that is lost in the noise about 10x is “Does a team with a 10x programmer deliver software better faster cheaper than a team without one. More formally is a team with a power law distribution of talent more productive than a team with a normal distribution of talent.”
That is IMHO the question that really matters in terms of modern software delivery. Any thoughts on this question?
Of course, the smart choice for orgs is to do both. If I had to choose a single (and I don’t) I’d go with a few 10x progs over dozens of 1x because small teams work better in general due to coordination overhead.
This is no excuse for letting 10x be jerks and I would probably run away from any hiring notice that talked about 10x. I think this follows my observation that smart people don’t talk about being smart, they be smart.
Prior to being downsized at a multinational, I was asked to explain my database update scripts to a lady who had never seen SQL. Some of the queries took most of a page. That system slowly sank into the sunset. It's hard to do customer support when the database doesn't know about their new machines.
It feels like these myths busters are a bit left leaning.
Sames as a topic about whether Tim Cook deserves his huge pay/bonus, to which the answer to the left leaning academic is, can you find a replacement for him?
If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.
You also don't get to be a 10x developer by kneecapping everyone around you.
Whether trying to find 10x programmers is a good HR strategy is a separate question.
This article is just a stream of consciousness brain dump, which I guess proves that 1/10x clickbait authors exist.
I get the sense that some of this constant myth busting comes from HR people who want people to be interchangeable parts and don’t like it when they are not.
Their analysis: 10X developers are a myth.
Alternative explanation: 0.1X managers are a reality.
But I’ve worked with a lot of people over the years who I thought of as 0.1X. They often just don’t seem to care.
But I've been 10X better than apparently average a few times a few weeks at a time. Uh, part of the reason for a few weeks at a time is that as part of the 10X I got the work done very quickly!
My 10X cases were all when the planets happened to line up just right and, to use a baseball analogy, the work to be done was like a slow pitch right in my best strike zone.
(1) I was seeing a girl, and she was an intern and working for someone who wanted her to work on some old Fortran code. She couldn't figure out why the code was giving totally garbage results.
I glanced at her code and saw where she passed the constant 2 as an argument to a subroutine. So, sure, that can be dangerous. I glanced at the subroutine and, yup, it was changing the corresponding parameter so for the rest of the execution of the program the constant 2 had the value given it by the subroutine and was not 2.
She worked a day or two on this, and I solved it in about 180 seconds.
Why? I'd seen that in Fortran usage before.
(2) I was in a software house working as a programmer and fast Fourier transform expert at a US Navy lab. Some engineers at the lab needed an extensive software project done and set up a competitive bidding situation. For one of the engineers, part of the work to be done was some power spectral estimation of ocean wave noise, that is, quite low frequency. Due to some earlier experience at GE, I knew the basics of the Wiener-Khinchin theorem and also got the Blackman-Tukey book on the statistics of power spectral estimation, typed in some code to generate synthetic ocean waves and accumulate and display the power spectra estimates, then called the engineer and we met and reviewed my work.
The main point I had for him was that for the very low frequencies he was interested in, he could need dozens of hours of data and with much less data than that would be looking at small sample statistical fluctuations instead of good estimates of the actual power spectrum. Likely I got these results in 10X. Our software house got "sole source" on the work.
(3) I was at Georgetown University consulting in applied math and teaching computer science courses when a friend from college called. He flew up to Georgetown with several other people, and we met. Everything was inconclusive -- no one had any definite, good ideas. The problem was scheduling the fleet for FedEx. That was important because some Members of the BoD questioned if the fleet could be scheduled at all; crucial funding was being held up; the company was at risk of going out of business.
Finally in the meeting I just blurted out that I would solve the problem. Six weeks later I had the software running which was also the end of the semester for my teaching. I flew to Memphis, ran my program, pleased the BoD, pleased the founder F. Smith ("solved the most important problem facing FedEx"), and saved the company. I suspect that in time, that was a 10X effort.
(4) I was working on a Navy project to support both my wife and myself through our Ph.D. degrees when the Navy wanted an evaluation of the survivability of the US SSBN (ballistic missile submarines) under a scenario of global nuclear war limited to sea. They wanted the results in two weeks. That timing just fit -- my wife had a vacation planned for us at Shenandoah just after the two weeks.
From a WWII paper by Koopman's, I saw a continuous time, discrete state space Markov process subordinated to a Poisson progress and wrote and ran the software, Monte Carlo. The software was fast enough that I could generate and average 1000 sample paths quickly.
During a peer-review, an objection was that there was no way I could "fathom the enormous state space". In response I mentioned that after, say, five days, the number of SSBNs left was a random variable; it was bounded and thus had an expectation; the expectation was finite; the random variable had a finite variance; the law of large numbers applied; and averaging 500 sample paths would give quite accurate estimates.
I explained that intuitively Monte Carlo put the effort where the action was, and the reviewer, a well-known probabilist, responded "That's a good way to look at it." My work passed the review.
A second person, actually two people, had been assigned as an independent effort. At the end of the two weeks, they made no progress at all.
The Navy got their results on time, and my wife got her vacation on time.
(5) When I arrived at Georgetown, a prof had just completed a statistics package. One of the routines was polynomial fitting, but on testing the numerical accuracy was poor. The prof had programmed normal equations, and on that problem the normal equations are close to the notoriously ill-conditioned Hilbert matrix. I wrote a replacement routine using some orthogonal polynomial methods and got accurate results.
(6) I was in an AI (artificial intelligence), expert systems, project at IBM's Watson lab, and we were developing IBM's language YES/L1. We wanted rule subroutines. Our code design was to (A) return one call at a time from the whole stack of dynamic descendancy, (B) execute the RETE algorithm run-time code, (C) rebuild the stack of dynamic descendancy. I saw serious semantic problems with this approach and the coding was to take some weeks. I got some dinner, wrote and ran some illustrative code, in effect to call back into the stack of dynamic descendancy, at dawn wrote email to our team, got some sleep, returned at noon, and our programmer on the work was done later that day. I got an IBM award for the work.
There were a few more 10X examples.
I always put my pants on one leg at a time and have never walked on water in warm weather. None of these examples involved high stress. Instead the keys were context, e.g., I had everything I needed and background so that the work was in my strike zone.
I don't achieve 10X all the time. Heck, I don't achieve 1X all the time; e.g., in my startup recently I've been interrupted and slowed by some unpredictable exogenous obstacles. But now it appears that I've circumvented the obstacles and am making good progress again. Back to it.
Net: I don't think anyone can achieve 10X consistently over long time intervals. And I don't believe that very many people can just decide "next week I'll do 10X work." and be able actually to do it. Instead I suspect that most people can have 10X periods given the luck of the right circumstances.
* Fabrice Bellard
* Linus Torvald
* Chris Sawyer of Transport Tycoon
* John Carmack
* Ken Thompson
* Jeff Dean
- There are 10x as many pretenders for every one real one. Management might mistake the fakers for the real ones because they are faking it on being charismatic. These engineers wreak havoc on teams.. everyone else is cleaning up their mess, the fake 10x gets all the credit due to the charisma and ego and too often the rest of the team isn't able to reveal the true situation. Management will often give these guys (never seen a fake 10xer who was a woman) huge accommodations and let them go off on massive projects outside of normal accountability and project management and when they come back a year later they've produced a big mess of garbage but a year was spent and the guy is charismatic so management has to have it in the product.
- Any given engineer might be 10x more productive in one organization than another. This can probably be indirectly correlated to the size of the organization
- Fake 10xers can drag down everyone else's productivity, and make themselves look better in the process.
- Real 10xer will produce an elegant architecture or solution that is easy to maintain and understand. The faker will produce a mountain of code with hidden bugs and put on an air as if no one else is smart enough to understand what they've produced.
- There's an element of "emperor's new clothes" with revealing a faker. Everyone knows they are a faker except management, and yet it feels impossible to stop pretending and pull the curtain back.
- Non-technical management makes it much easier for the faker to get their hooks into an org. Maybe the UI designer got elevated to VP of engineering and doesn't know much about code. Maybe a junior guy got promoted for being one of the first employees. These kinds of managers are juicy targets for fakers.
- Fakers often seem to introduce new tech to the stack so they can show it off on their resume, even if it doesn't fit the product well.
- Fakers make up clever names for everything they write as if they are marketing their code. Put stuff off in a separate library in a separate repo when it could have fit right in the main repo. Give it a clever name. Convince management to allow them to put it on github as open source so they can polish their external cred.
My last two positions the team was essentially sabotaged by a fake 10xer on each project. Reams of buggy code and huge management accolades, when the bad code starts to catch up to them them move on and leave tons of tech debt behind, and they move on to do the same thing at their next position. One of these guys spent 3 years writing a crazy library that used an alternate persistence strategy and when it got put in it destroyed performance to such an extent that when he moved on the whole thing was removed in a month or two and performance went up 100x just by changing everything back to a more standard persistence strategy. Meanwhile alternate persistence strategy went all over the guys's resume/LinkedIn.
Or another individual who can make all of your developers 5x more productive, because that individual created a framework/algorithm/model that is radically more productive than what existed before (e.g. think Jeff Dean at Google, DHH with Ruby on Rails, etc)?
It seems very obviously that some people operate on another level than others. If methods exist to boost the "normal" people to the genius level, they have not found their way into the mainstream yet.
Surely you could bog them down so that they don't perform better than the rest. You could simply only have boring software issues to solve in your company. In that sense, maybe you could get rid of the 10 times developer.
Or you could hire only very good people. But looking at the sea of developers, it seems clear that some are better than others.
FILL YOUR EMPTY FUNGIBLE DEVELOPER SEATS WITH OUR FRESHLY TRAINED DEVELOPER CATTLE FROM SCHOOL OF PROGRAMMERS #36. CERTIFIED IN AGILE BEST PRACTICES AND ADVANCED JAVA BEANS. 2 YEAR SERVICE LIFE. PRODUCT OF DJIBOUTI.
