The myth of the myth of the 10x programmer (2020)
payne.org
payne.org
In my 30 years I’ve both been the 10x and managed 10x programmers. Their skill isn’t in programming, it’s in reducing ambiguity rapidly and advancing efforts through complexity rapidly. It’s in taking the initiative and in developing a depth and breadth in what “Right” looks like and knowing how to achieve it. It’s in having mastered not the ability to write code, but to read other peoples code and improve on it rapidly. It’s the ability to spot a defect or bug and know the solution instantly for a normal bug, and know how to successfully debug an extraordinarily difficult bug.
Saying these people don’t exist is absurd. Saying that in any practical sense our career is solving “well defined programming problems” is doubly so.
Edit: I’ll also add, 10x programmers don’t make everyone else less valuable on the team. First, they make everyone on the team more valuable. But there’s also an incredible importance in being able to take a direction and methodically work it to conclusion. These are the workhorse programmers. You only need one 10x programmer. Their force multiplication doesn’t work on each other. They also can’t do everything alone. So while they’re valuable, they’re not valuable without the team around them. And in my experience they can’t stand not having a team around them. Part of their ability is their empathy for their peers and their internal necessity to help people solve their problems faster.
They Know Their Shit. They won't remember details necessarily off their head but they don't need to look up notes.
When you talk to them, it's like they just pulled up the Complete Lego Block Reference in their head and are snapping the pieces together. They can't tell you the exact size of a piece but they have a hunch that some piece A probably exists that probably snaps to a B piece to deliver what you need.
However, in the real world software engineering is hardly ever just about programming. As a permanent employee there is a lot of time sink in attending meetings, town halls, compliance training, performance reviews and just generally sucking up to management to ensure you get the promotion you want.
"Ten times programmers" often heavily rely on their team to be able to be this efficient. The worst ones rely on their team to fix their hacky codebase as they move on to a new project.
There are 10x programmers, and even higher. On certain tasks you won't see the difference at all. Are you John Carmack-good? I'm not. Let's be big enough to admit it!
Think of it like Opera. The average singer can't hit the high notes, and no matter how much time they are given, they may never. If you just need to sing happy birthday everyday, the average and amazing singers might seem equivalent. They're not, though.
> Their skill isn’t in programming, it’s in reducing ambiguity rapidly and advancing efforts through complexity rapidly
You should make a top-level comment if you plan on ignoring context.
If you are free to decide how you work you can get a lot of things done.
but no, either you've never seen or experienced one or else you don't recognize what you just saw. people who are oblivious to their own capabilities, or lack thereof, wouldn't recognize the difference.
It is also worth reading this
how many books have you written vs. Donald Knuth? Richard Stevens? etc. those are just famous examples. do you think you have approximately the same skill as yo-yo ma? is he not approximately 100x (or more) what you'd be at his job? i don't think it's a stretch to say he's about 10x of the average professional cellist.
as other have pointed out talent, productivity, whatever measure you pick generally follows a normal-like distribution. if you center that bon "1x", most people are about average. 10x, 20x exists, but it might be quite rare. -1x also exists, as do -10x (e.g. that guy who single-handedly destroyed the project via mismanagement, ego, incompetence).
to not recognize this is just simply naive or you can't appreciate other people's talents.
I agree there is a normal distribution, however, I disagree about the width of the distribution. The variance is much smaller than you think
In my experience at places like AWS and other FAANG my observation is it’s at a rate of about 1:300 engineers. In other top employers it’s closer to 1:500. In startups it’s probably in the 1:800 range. In your average tech company probably around 1:1000, and in hideous soul crushing companies literally zero.
And often even when you look at the legends, there is a large chance they would not succeed in a standard office. For instance Wozniak begged HP to put him on the computer team, they wouldn't do it. Despite the fact that in his off time he was achieving more than the team they had assembled.
Carmack dropped out of college. He would be ignored by HR today. We know what he is capable of - he's a legend. And yet in his Meta keynotes he continually talks about working on a problem one day a week and by the next week the environment that he left it was worse than before he improved it. Quest was getting worse faster than he could fix it.
How many 10x developers are put in 0.1x environments and just look normal?
"rare" i agree with. that's a far cry from being a myth or not existing. "The 10x programmer doesn't exist", i think is what you said - don't move the goal posts.
they are clearly somewhat rare, how rare is a pointless argument. but they exist and i'm glad you have acquiesced to that fact. i hope you have the privilege of working with one someday.
>I agree there is a normal distribution
Pick a lane.
You seem to think engineers in a FAANG somehow don’t actually exist or something. Yes FAANG and other top tech employers employ a disproportionate amount of 10x engineers because (a) they recognize their existence and seek them, (b) they give them interesting work and autonomy, (c) they pay them enough no one else can poach them. They are already rare - I don’t know why, as someone who has been recognized as one throughout my career despite my own impostor syndrome I can’t identify anything special about myself, or give advice on how to be a better engineer more than the average advice. As a hiring manager i am self aware enough to identify 10x engineers and they tend like working for me. I have noticed it’s a waste to have more than 1 per team, so I try to spread mine around. But I will literally pay any price to hire and retain them because they often make a project possible that is otherwise unlikely to succeed, and they lift everyone around them and improve them through out their career.
I hope you get a chance to work with one. Or maybe you are one and like me couldn’t see it?
Which is why i like to talk about 10x engineers rather than just focusing on the development part.
My brother's car kept going into paroxysms where the engine would stutter and want to die, at random times. He'd pump the gas etc and it would go away.
Never happened when he was at the shop, so the guy said "If it does it and you're anywhere around, drive right in and show me!"
Kind of a long shot but what could he do? So one day it happened around 5 and he was close so he pulled in.
They shop guy listened a moment, said "don't do anything!" and ran and got a vise-grips. He shimmied underneath the car, clamped the fuel line. Waited until it almost died, then released.
The problem disappeared! It purred like a kitten.
"It's almost 5, I want to go home, but bring it in Monday and I'll take care of it."
"You have to explain that!"
"A piece of grit got into your needle valve (fuel rate control). Starving the engine made the valve fully open, and the grit passed through. I'll replace your fuel line and filter, problem should go away."
And that is where the finances come in. Why pay a 10x mechanic 300k/year if he is only going to generate 40k more in revenue than someone who would work for 90k/year. Where a 10x SRE/Cloud Operations person could actually save you 300k/year
In software, we don't yet have a profession of Maintenance Engineers who can put up a shingle and strace/kernel debug opaque software experiences as a regular "practice."
---
Upon reflection, I realize free and open-source software fills this slot in a sense.
It's the analogy. Also, your numbers sound entirely made up.
I would not hire SRE to save me 300k a year, I'd hire them to make me 600k a year.
It's possible for someone to be 10 times more capable of diagnosing problems, but they don't fix 10 times as many cars.
If this was actually relayed by a mechanic they were trying to get you to go away. It's more likely a story created by someone with a rudimentary idea how these things work who imagined it illustrated their point.
What I strive for my whole life is to develop this kind of telepathy which allows me to know events/skills better than people who actually lived them or developed them.
Yep. And as cognitive tasks become more challenging the distribution of ability actually widens.
As an extreme example, how much more productive was Andrew Wiles than the median mathematician at the task of proving Fermat’s last theorem? Pretty much infinitely more productive I would say…
"Fake team microservices" is when you have say like 7-10 devs in the company, and 50 libraries and 15 microservices. The microservices are real, but the team "size" is faked.
People moved on from monoliths way to quickly and it's ruined my productivity. I actually thought my brain was slow and I was getting stupid recently. Then I did a programming test (interview). I burned through it so fast that I realized most of my mental blocks are NOT wanting to work for the company I am currently employed. My wife just nodded in complete agreement when I came to that realization.
I want to be a 10x again and I realized when companies focus on the wrong things, that breaks the 10x.
That's assuming good intent, worse intent is that devs want to experiment with different languages or generally want to avoid learning what everything is in the codebase or they are unable to use their editor properly to navigate large codebases efficiently.
There is absolutely no reason to split the codebase and subsequently the test-suite ever.
You can always take a monolith codebase and deploy it differently with the configuration driven by environment variables. (e.g. external vs. internal API's). This way your test-suite remains unified and can test the entire application.
This is simply not true. Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources. The organizational problem is solved by the hard boundaries and loose coupling imposed by operating and consuming independent services. Allowing a team to own and operate their services allows them to have more control over all aspects of a their life cycle, reducing the scope of other stakeholders to what contract their interfaces need to comply with.
Those who naively shit on microservices seem to be totally oblivious to what it would be like if all we had were monoliths. We tried that already. It's awful, and we learned from that mistake. Well, some of us did.
"A" solution does not mean the only solution or the best solution. They're often treated as the only solution though.
They are often, and by far, the best solution though, specially taking into account the tradeoffs of whatever alternative you come up with.
Specially massive monoliths in a monorepo.
It makes no sense to mindlessly crap on operating services, specially when compared with alternatives. I get that some people feel the need to vent their personal frustrations, but this does not mean they have a point.
Are you trying to solve a problem with code organization? I've heard of folders, they do a pretty good job. Most of the time though, microservices tend to get in the way of delivering VALUE to the company I work for ... because someone thinks 'this is the way.' I was hired to deliver VALUE, not beautiful code, not code that follows this year's 'best practices' that aren't, or even bad code.
I will always write easy, simple, and clear code that delivers VALUE. Microservices usually get in the way of doing that, for basically arbitrary reasons.
As I've already said in this thread, microservices solve primarily organizational problems. They define concrete organizational barriers and limit discussions with stakeholders on issues pertaining to service contracts, and ensure that service owners have complete freedom, responsibility, and clear accountability, on all aspects of their design, maintenance, and operation.
Scalability is a welcomed benefit but lower in importance, below reliability and perceived performance.
Any other discussion on microservices boil down to strawmen.
If I could pick one thing to talk about when it comes to microservices it would be the name. Micro implies microscope, implies there should be millions to billions of them.
If we could switch to the term two-pizza-services as your comment implies where their main point is in working around Conway's Law, I would feel a lot better about them.
Once your team loses the rapid feedback of "did this break user-facing functionality yes/no?" your reliability and speed of shipping features deteriorates rapidly as now most engineers will start to fear shipping to production.
Ideally, you break the team into subteams and follow the natural fault-lines in the codebase. Most codebases have areas that do not interact much (or not at all) with each other and they lend themselves well to assigning to a specific subteam.
I'm sure there's a point where this breaks also but I haven't reached it yet.
They are not better than modules. The problem is that dynamically typed languages can't support proper modules, so microservices are their only alternative (so far).
They are. You don't control your runtime environment with modules, nor your deployment. You create problems due to the need to manage releases and deployments. You can break everyone's work if you make a mistake, which worsens the problem. You are unable to pick and choose what technologies you use. Etc etc etc.
With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that.
These problems still exist with microservices, you just don't see the problems at build time but in failures at runtime. You yourself admitted this in your last paragraph:
> With a service, you just tell everyone where it is and what's the interface, and leave it to everyone else to work around that.
So basically you've moved code problems into infrastructure problems, and eliminated standardized build and testing pipelines in favour of a free-for-all/not-my-problem.
And if you think microservices are special in some way, I could also say "with modules you just tell everyone where to download the package, the interface and documentation is bundled with it, and leave everyone else to link to it and use it how they see fit".
The only real difference is that the module is guaranteed to work according to the interface specification you're expecting because this is enforced by the language. Not so with deploying runtime services.
Edit: I also don't understand this at all:
> You don't control your runtime environment with modules, nor your deployment.
Why would you need to control your runtime or deployment with modules? The language already specifies the semantics of modules' runtime behaviour and their linking requirements, and the standard build process is deployment.
Having it all together is perfect for code re-use and testability.
It's also very easy to know if you broke the bigger picture while working on a subsystem of the monolith because the test-suite will tell you.
In my humble opinion, monoliths are unpopular because not much thought went into the original design of the code and as a consequence there are large chunks of technical debt interfering with everybody's work. It certainly doesn't help that many popular frameworks don't give you the design architecture to grow big apps.
But the good news is that if you don't split your teams, you also have more engineers on hand to refactor the codebase to be more manageable.
There are always reasons for and against any decision. Engineering is about balancing those tradeoffs to meet your particular needs. It's silly to say "there is absolutely no reason to ..." about almost anything.
I found that's the real productivity killer. The whole microservice bonanza is still not my favourite approach, but with the right tooling it can work okay. If you don't have good tooling that's actively maintained (which is the case more often than not) ... yeah, your productivity will drop to nothing.
That's far from my experience. In all the projects I worked with that involved services, the very first thing that was setup was a working local test environment and at least a non-prod stage. With tools like Docker compose and any of the myriad local kubernetes clusters this is outright trivial.
If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture.
Once I worked on a legacy desktop application project that didn't even had debug builds. Would it be fair to pin this failing on how awful desktop apps are?
n=3. All small companies. I'm sure this isn't representative of all companies, but I also never claimed that's the case. Smaller companies tend to have worse dev tooling in general, so not a surprise this extends to this, too.
> If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture.
Running 15 servers is harder than running 1 servers. These things are certainly related. It's not "trivial" to run any of this.
It's not "on me"; I joined long after all of this was set up. Usually there seems little interest in getting anything going, it's all pretty complex and often undocumented, so not so easy to "just" fix it by myself either, and after a few weeks or months of basically getting fuck all done I've ended up leaving (
Except it is. It's bad form to go down the "everyone else sucks and I'm flawless" path that plagues software development circles. You work on the project, and it's on you to get it in working order. Setting up a basic local software dev environment is step #0. Just because your predecessors failed to set one up that does not mean you're not to blame for failing exactly like your predecessors failed, except your predecessors didn't tried to throw you under the bus.
Also, it is a collosal red herring to talk about dozens of services. You can and should fake services you consume to isolate the services you actually work on. It's also bullshit to pretend that nowadays there is no way to launch and shutdown dozen of services in one go. It's trivial to launch them locally with multiple technologies to choose from and trivial to setup cloud environments for development purposes. These are all lame excuses, and one that illustrates problems caused by the developer's inability to go through the very basics.
> It's bad form to go down the "everyone else sucks and I'm flawless" path
Except I never said anything like that.
> It's also bullshit to pretend that nowadays there is no way to launch and shutdown dozen of services in one go
I never claimed "there is no way" to do this.
> These are all lame excuses, and one that illustrates problems caused by the developer's inability to go through the very basics.
I'm not going to join an organisation and tell them "you're all doing it wrong!" in my first week. I might make suggestions, and if they're received with "meh, I don't see the issue" then I'm not going to press the issue to an unreasonable degree, or work on things I find important regardless, especially if they don't directly contribute to the product that's being built.
You somehow failed to read what I actually said, and proceeded to go off on a non-sequitur.
I repeat what I said: it is trivial to launch and shutdown multiple services in a local software dev environment. It's trivial with Docker, it's trivial with minikube, it's trivial with microk8s, etc. It is a solved problem. Why is anyone trying to pretend that this is impossible?
Enough excuses and scapegoats.
> Except I never said anything like that.
Except you did. You tried to claim that the small teams you were involved failed to setup working software environment because reasons, and that was the reason why you also failed. Bad form. You own your work.
> I'm not going to join an organisation and tell them "you're all doing it wrong!" in my first week.
Bullshit. It makes zero sense to forego setting up a working dev environment as the very first onboarding task, and excuses like "being able to debug would make team members pissed" is absurd. Either you can do your job or you can't, and throwing your team members under the bus like this is bad form.
We need a counter-movement for the latter.
I work on two microservice cloud systems at the moment: the first I was the first person working on it day one, and have been involved in every aspect including devops & support for the past seven years - I'm far and away the most producive developer on this system.
With the second system, there's another developer that's driven the team for the past few years and designed everything from the start, and they are easily the most productive person on this team. Probably 3x everyone else and its a strong team.
Its just that I know the second system less - I know roughly how everything works, but haven't poked around in every corner of the system like I have the first. For larger systems this kind of knowledge can take years to build up.
> seem very confusing to grug
One level of indirection up, it would be nice to have this as scaffolding, and a script would pull in (containerized) services, injecting the appropriate env vars and the like.
We would (or should) be able to debug things, because we control the layer on top. Maybe intercepting network calls, redirecting requests from the container--the possibilities are endless.
Examples: Team a needs version 6 of a dependency Team b is using version 5, and there's serious compatibility issues Team c is writing something in Rust which makes sense for them, but not teams a and b.
The 10X meme is both too extreme, by implying that Fabrice Bellard could kick out simple crud tasks at 10X the speed I do, and not extreme enough, suggesting that I could build ffmpeg and qemu the same as Fabrice if I was just given more time.
And also, the 10x meme, and how it’s often used, implies that skills are interchangeable. Should a great database internals expert be able to build a great micro-services architecture?
Earlier post:
I understand your point and I think it just reinforces the fact that the "10" in "10x" should not be literally parsed as a number. My previous comment about the common conversational usage of "10x" is just a synonym for "much smarter than average": https://news.ycombinator.com/item?id=13753178
Another example of a random comment where "10x" does not literally mean "mathematically multiplied 10 times": https://news.ycombinator.com/item?id=28784181
It was just another example of "10x" as a short way to type out "significantly better" and the "2x" as a synonym for "slightly better".
It clarifies that it doesn't mean that its 10x faster at tasks, like the original 10x study was about, but more just a shorthand for being of a different class of skill level.
If we’re going to talk about talent on a scale that is normalized to typical human abilities, IMO it would be better to assume talent distributed on a Gaussian and talk about n-sigma talents. We’ll end up sounding like Jack Donaghy though I think.
The way I see it, 10x programmers have something (or things) that most programmers lack. Usually some combination of raw intelligence, creativity and dedication, often combined with a much deeper understanding of theoretical fundamentals than other developers.
> And also, the 10x meme, and how it’s often used, implies that skills are interchangeable. Should a great database internals expert be able to build a great micro-services architecture?
As I indicated above, I think being a 10x programmer is not so much about learned practical skills as having innate talents, and then making use of them. Such talents can be surprisingly transferable between technical domains.
I know of cases where a developer unfamiliar with both a codebase and the language it was written in can, within an hour or two, identify bugs and vulnerabilities that the dev team spent months failing to find/fix.
I think one aspect of this is the ability to break ANYTHING down to first principles, when needed, without losing sight of the whole.
I've found that stuff like that was way easier once I touched few languages that promoted different paradigms (some low level, some high, object oriented, functional/lisp etc). It makes it much easier to see difference between "programming" and "programming language"
A 10X better engineer can do things others can not do.
If you give someone a task of a marathon, someone could complete it in 2 hours and another person 6-12 hours, but they both finish. If you give someone the task of lifting 500 pounds, it will never get done by most people.
Accidental complexity leads to more accidental complexity. When small errors early on build exponentially, you need to find those that can do so with minimal mistakes.
I don’t care if someone is 10x faster than average at building a CRUD app, but there are developers who come up with solutions that an average dev would never come up with, even given a lifetime. I’m talking about innovations like Lisp, Deep Learning, React framework, the first 3D engines, CRDTs, Git version control, Bitcoin, etc…
Building something like a 3D engine requires incredible mastery across multiple domains. The hardest part of these innovations isn't the software. It's developing an abstract mental model for the problem - repeatedly until it fits into an actual computer.
When I work on my most extreme projects, I find the hardest stuff happens while I'm sitting around the house or scribbling on the whiteboard. Anyone who uses lines or hours of code as some statistic for capability can be instantly flagged as charlatan in my book.
React is another good example. Absolutely nothing about it is a super deep pool of incredible innovation. The reason it's a thing is because someone had a very coherent vision in their mind for what the developer experience would be like. Then, they whacked at the workpiece until it approximated that idea.
10x is more about idea management than raw output.
the infinitely-better engineer is probably not going to be working at your company building CRUD apps.
Mathematicians don’t go around talking about professors in quantum physics with PHDs like they 10x high school teachers, etc.
I don’t understand why this is a topic that keeps coming up.
1. There are people who are 10x better at working in one codebase simply because they have so much experience with it.
2. There are people who end up leading a great lab. The sum total of their circumstances end up making them 10x more productive than their colleagues in their field of research.
3. There are people who can be dropped into an unknown research/development environment and be productive 10x faster than others.
I think people mostly mean 3. when they talk about the 10x programmer. Anyway, does any of this really matter? If you are a 10x programmer, then you should make sure you get compensated for it. And if you aren't, you really do not want to get confused for one as the pressure of expectations will make your life miserable.
I personally believe most people reach their optimum lifestyle subconsciously. A 10x programmer gets there because (he (or she) is naturally talented) and he has enough interest, desire and willingness to commit his time to become 10x better. If you aren't a 10x you probably also do not really want to be a 10x, because you probably value spending your time elsewhere or just do not truly enjoy the stress that comes with such a role.
Basically what I want to say with all of this is:
1. There are definitely some people who are heads and shoulders above others.
2. But in many cases a 10x is a 10x in their natural environment. If you remove them from their natural environment they won't replicate their success, even if their natural ability is also very much above average. We tend to attribute all the merit to the leader and forget all the people working under him.
3. You shouldn't concern yourself with how high you rank in this hierarchy. Do what you feel comfortable doing and enjoy life. You probably subconsciously chose the role that most accommodates your lifestyle, anyway.
I think I might have veered a bit off-topic.
> In academia there are definitely people who are heads and shoulders above others, for example [my emphasis].
GP was providing support for their claim that 10xs exist in most fields. Academia was just one example of a field (or "field of fields"). The same could be said of farming and plumbing.
- The one who is 10x at the expense of their colleagues (they run fast and break things and leave to others clean what is broken, which is part of the reason that they are fast).
- The one who is, at most, 1.5x or 2x but think they are (and sell themselves to the leadership as) 10x and get a very disproportional part of the money, promotions, praise, notoriety.
- The one who really is 10x, knows it, everyone that worked with knows it, but they are just obnoxious about it. They consider themselves not just a better programmer but a superior human being. This one at least is productive and can be dealt with good management.
So when you have met those types, especially the first two types, it is natural to have sympathy to the idea that 10x is a myth. But, for me, it’s clear that they exist and some of them are nice people and great to work with, they are 10x in velocity and code quality, so they make your life easier as a programmer next to them.
That is to say, some at this type surely can be managed, but it may take a really good manager (and even that may not be enough), along with team mates who are not only good, but also able to deal with such a team member.
Which in the end may negate the 10x productivity, or at the very least reduce it.
I guess one alternative is having them in their own “team” basically reporting to a director but having no immediate team members
I’ve been the 10x programmer several times in my career. Interesting positions that kept me hyper focused. Built out entire product lines, saved or made companies millions.
I’ve been 1x or much lower on uninteresting projects, or ones where I couldn’t get management to deal with blockers.
Some of these have been at same company. Just depended on the project.
In that case they are not 10x. They are not producing 10x value if they are making it harder on their coworkers.
> The one who really is 10x, knows it, everyone that worked with knows it, but they are just obnoxious about it
In that case they are still not 10x because if they aren’t reined in, no one wants to work with them and work still gets done slower - again not producing 10x value.
There are plenty of smart pricks in our industry.
Also if you produce code and don’t bother leveling up your coworkers, you’re a long term liability to your company.
It's like insisting that surgeons are terrible people and pointing to Jeffrey Dahlmer because he also cut up people.
The core issue is the disconnect between leadership and other engineers: the leadership heaps praise on this person, gives them interesting work, and takes projects they think are “behind” away from others for their superstar to work on. The other engineers are left feeling resentful that they have to fix/maintain/extend/support this horrible tangled mess of code, while the “10xer” moves on and never has to deal with cleaning up their own mess. Sometimes management will actively protect the person’s time by asking others not to bother them with questions about their code while they focus on whatever’s next!
The features shipped have visible business value and are easily measured, but the impact on employee morale/retention/velocity is harder to measure, so it’s overlooked.
Yes. I've encountered more of these than I have 10x developers. In fact, I've FIRED more of these than I've encountered 10x developers.
That doesn't mean 10x developers don't exist.
Whole idea is taken out of context. There is nothing about "superhuman 10x dev" it was simple realization that IN ONE TEAM there are developers who are 10x faster to deliver tasks and there are slower devs.
Just like in university group assignment there are slackers and there is that one person who does the assignment.
Worst of all is that people start assigning "10x" to themselves or others or judge others as "0.1x" - which is meaningless out of very specific context.
Programming, at least complex programming, is a gestalt of many skills ALL of which are probably a normal distribution (intelligence, focus, problem solving, political savvy, curiosity, experience, etc. etc.) How could it NOT have at least a 0.1x to 10x distribution?
More so it means that there ideas, abstractions and frameworks result in substantially higher productivity for anyone working on the project than the average dev.
Beyond just the talent to do this successfully, you also have to give people the space and freedom to actually do 10x work... This tends to extend well beyond the narrow scoped requirements written in the current sprint of tickets.
When talking about 10x devs (or 10x any type of employee), it is about Judgement. The decisions they make on what they work on, how they achieve it, and (probably most importantly) what they choose NOT to work on. Judgement is the deciding factor in whether someone has a 10x impact on the business over time. It absolutely is not how much code they write. As a matter of fact, removing code can be a 10x improvement as well.
Also, I do think there are 10x programmers that are 10x in a myriad of contexts, not just one team.
I am not botching your idea, I just have a different perspective of what the term “10x” means.
*Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring perfor- mances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and per- formance. (I doubt if that is universally true.)*
Now, is that really the 10x:ers fault?
People I have met in the the third type (true 10x-ers who know it) seem to have a lot more humility, in my experience, than suggested here. If you look solely at metrics like kLOC/year, they are often in the middle or bottom of the pack. They are not usually generalists, instead specializing in some area that is of high value.
When a single individual outperforms a large group the large group typically doesn’t like it, or the person doing it. Sadly that’s just a part of human nature. Where I live (Sweden) it’s referred to as the law of Jante. In other parts of the world it’s referred to as tall poppy syndrome or crab mentality.
I have a friend like this. I have never worked with them, but get to hear about how all their teammates are nearly useless on every team they work on throughout their career (mix of FAANGs and startups). Every time they join a company, they quickly become the team expert and biggest contributor, because they enjoy working long hours, spending their weekends coding, and are a very talented programmer.
I recognize they are extremely passionate for what they do, but I would never want to work with them personally. That kind of work relationship cannot be fun for anyone, except maybe the stake holders that are seeing rapid progress.
The one who is 10x at the expense of their colleagues [...]
The one who is, at most, 1.5x or 2x but think they are (and
sell themselves to the leadership as) 10x [...]
The root issue, of course, is that management essentially never has the time or chops to discern the quality (maintainability, readability, performance, correctness, etc) of the engineering work being delivered.
Management only understands timely delivery. Which is crucial, obviously! But considering only quality or timeliness at the expense of the other is of course a dark dark pattern.
Even when management are software engineers themselves, they typically just don't have the time to be elbow-deep in the code their reports are delivering. This is particularly true in fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks. And even if your manager does get it, their manager probably doesn't, their manager's manager doesn't, the stockholders don't, etc.
I don't know the answer to this. It seems to me almost impossible to avoid this in a commercial setting unless you have a tiny team (less than 10 engineers?) and the CEO/CTO is a top-notch engineer.
Talk me down off of this ledge. Tell me it's possible.
as they should, because it's the only thing that matters to 99% of humans for any non-critical stuff (and honestly, even critical... even stuff that can kill humans, we are very good at saying "one chance of death in XXX is an acceptable risk" ; I'd wager that anything that is below the average death rate of car driving in a particular time / area is in general ok).
I'd rather learn a software that has bugs today than a perfect software in a year - by that time I've already organized my workflow around the bugs and already spent 1/30th of the time of my projected remaining future career around this software. I'm not going to re-learn yours even if it works better.
as they should, because [timely delivery] is the
only thing that matters to 99% of humans for any
non-critical stuff
The tech debt you accrue today in the name of "shipping fast" hurts your ability to execute timely delivery in the future.
That's why management should care.
I definitely agree you about the near irrelevance of tech debt in short lived projects.
the large majority is short-term projects which
But it really depends on if you're working at e.g. an agency vs. working on long lived in house projects.
Hate to break it to everyone but its really not like this, unless you're stuck in a loop of a bunch of resume driven engineers there's alot of stability in frontend development, especially since the advent of meta frameworks (Next.js, Nuxt, Modern Angular etc) and stability in tooling (rollup v2+, webpack 5+, and especially esbuild / vite)
If you want to be even more stable here, you can forgo a lot of headache with web components, which will always have some backward compatibility built in thanks to it being build on standards.
It isn't 2016 anymore. New frameworks aren't just popping up left right and center and expecting adoption. There's a lot of stability out there and there will be for the foreseeable future.
Much like any engineering endeavor there are, yes, people pushing the frontier, but all communities have this.
unless you're stuck in a loop of a bunch of resume driven engineers
- The one who is, at most, <INSERT ANY RATIO, EVEN NEGATIVE> but think they are 10x and get a very disproportional part of the money, promotions, praise, notoriety.
- The humble one, who helps mentor their colleagues to be better at what they do. They do this by helping provide critical insight at important junctures. By not attempting to grab the spotlight, but instead shine praise upon their colleagues.
These are people who help everyone get better. They are out there. While the first 3 are the loudest and most annoying, this 4th type is rarely self-identifying, often self-deprecating as they don't crave attention.
I've seen 10x that were excellent mentors. Perhaps not in a traditional sense, but through code reviews and answering questions. Everyone working with him seemed to improve really quickly.
I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.
I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.
There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally). When hiring is red hot, they might completely disappear from the hiring pool by junior year.
[0] https://blog.pragmaticengineer.com/software-engineering-sala...
[1] http://danluu.com/bimodal-compensation/
[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...
I think this depends a bit on your viewpoint. When most people think of 10x developers, they think of ten times their theoretical maximum output, not their actual output.
The highly productive people I met were good developers, but not leagues beyond in skill. They just had their work setup to not be bogged down too much by meetings, knew the application and had the ability to actually do productive work to the scale of something like 8-10h per day. If you compare that to your average developer, who will be somewhat impeded by management overhead, 'only' be reasonably skilled and max out at something like 4 fully productive hours a day (2 on Friday), it really seems like those guys can put out 10x the work.
It's also probably a lot of anecdotes, "this dev solved weird issue in a day where other dev was stuck for week and couldn't find it!".
They might be 2x developer on normal day but happened to be this or that, debugged some hard bugs everyone else got stuck at and the people in project remembered those few good performances and assumed they do everything that much better
I find that many people commonly believe themselves to be a >1x programmer who is simply misunderstood, which is damaging. This leads to them thinking they deserve more, and therefore can make less effort to compensate this delta, or imagining that those above them who disagree with their own characterization must be idiots.
Compare GRRM with Stephen King. Both are very skilled authors but one is releasing books like clockwork and the other has propensity for getting authors block. Is one of them a 10x author and the other not? I think the answer depends on your reading taste.
In comparison, the comparison of best-seller musicians suffers from how many times the economics of popular music has radically changed over a century. And music is already the product of many people even for something like "Joe Pass plays solo guitar inside his closet as recorded by a handheld potato". (He plays music composed by others! Also not really an example of pop music.)
But I guess the question of successful/fast/highly compensated vs skilled is probably also true of progammers too. Is a 10x programmers also necessary a successful one career wise?
I've found those who produce significantly faster do so by creating well justified shortcuts that do not sacrifice the end goals (but may run around the requirements a little.)
That's exactly the story in TFA: Someone decided "I'm not going to satisfy this silly requirement of writing tests, I'm going to just auto-generate some tests, regardless of whether this has full coverage of all corner cases, because I bet everyone is just happier to move on."
This is why I believe a 10x-er can be trained, by building a deep toolbox of solutions to pull from, learning to read the room when it comes to designs, and learning to recognize and take well-justified shortcuts whenever possible.
Of course, if he would be put into a completely new project, he probably wouldn't be 10x, at least not the first few years there.
That's also a misunderstanding: The original research that the "10x" label was based on was best-to-worst, not best-to-median.
Also (not so much to you but eh may as well just dump it here): it was "in a given group of experienced programmers". Basically could be thought of as "within a given team". It never meant a single person was themselves always 10x or whatever.
Well yeah, that's what I'm saying, but thank you for bringing it front and center in a clearer way.
I think the total output is still quite high compared to other people, but I’ve spent most of my professional life torturing myself for being “lazy” because my work patterns don’t look like other people.
I'm something of a 10x designer who can program, a bit. As a result I've produced a working library of products easily 10x the size and scope of most competitors, within some very obvious constraints because I am NOT a 10x programmer, per se. My effectiveness is in coming up with the things to do, and why, and implementing them in such a way as to maximize their reach and usefulness.
I'm currently working with a 10x programmer, whose capacity is astronomically beyond mine as far as programming is concerned, but who's simply a good designer, not a 10x designer. So his projects tend to be user-driven and expansive, and very useful and dependable, but rapidly feature-creeping because he's not really one to tell users 'no, you can't have that, it's not in line with the vision'. His 10x is in the ability to bring all such requests to fruition, for many parallel projects.
We're collaborating on a thing and my overview/observation is this: when you're able to get the people working cooperatively AND trusting each others' 10X domains, it multiplies. I figure me and this guy combine to be a 100X, if and only if we consciously work towards maximizing that.
The experiential thing about being that person in that situation is the EFFORTLESSNESS of it. It's really pretty mind-blowing. Requires good enough people skills to be able to observe, listen, and trust. But when you luck into that kind of combination, it feels totally Woz/Jobs. Stuff just unfolds, perhaps with a lot of enthusiastic work (I'll happily put in days, weeks, months of grind on things at my level that will facilitate the project) but it's important to understand that it's not 10X or 100X the effort or burden.
Being in that 10X situation is great, and you should be able to be there in such a way that everybody's delighted and facilitated by what you're doing. If it's a burden on others or giving them a hard time, it's not the 10X/100X thing I've experienced. It's not a struggle. It's about when things just go great, seem to burst forth effortlessly.
The resistance against that type of developer is probably from the rest of the team who get to clean up after them but get none of the recognition.
But, here's what's most typical in my experience:
4. A programmer who writes a bunch of code and delivers a bunch of features early in a project's history. Because management typically does not have the engineering chops to determine the actual quality/maintainability of the code being delivered, but does highly value rapid delivery, this process overwhelmingly selects for developers who are deliver sloppy but (mostly) working code at high velocity. Additionally, they are the only ones able to understand how the existing mess works, because they are the ones who created it. So everybody else works at a disadvantage. This further cements the belief that they are "10x" and they are rewarded with more and more greenfield work and they usually make a mess of that as well while management continues to think they're geniuses.
I've seen 10x folks in the other 3 categories be total assholes too.
I think the "debate" around 10x folks is a bit silly, and by hard-earned experience, I've learned to question the motivations of the folks who deny that such engineers exist. There is a whole other sort of politics going on, and, it doesn't address the core problem.
My experience of 10x folks is more like: can you live with them, will they be a boost to the team overall, or will they use their 10x to bring down folks around them (consciously or subconsciously) so that they can appear to be more like 20x, or something petty like that.
Some 10x folks use their 10x to put everyone else at a disadvantage, by forcing people to play their very specific sort of game (happens especially with strong specialists who are also decent generalists, i.e. T-shaped people).
There are others who use their 10x to resist any changes, typically out of some seen-it-all cynicism (happens with the crowd who are really good at some codebase, or who are leaders of their lab, etc.). The damage caused is difficult to dislodge because it's based on context as much as skill, and learning the business context can take years, which most talented people won't have patience for – if the 10x even allows them to exist.
Every sort of 10x has some dark pattern (alluding back to your experience), and for that reason, I think it's important for "good" people to not let whatever 10x they have get to their head, and to find other things in life that offers them non-attachment and perspective. It isn't necessarily a strong-people-be-assholes problem as much as a human nature problem. Left unchecked, 10x becomes self-defeating at a team or org level, and will make the 10x person miserable too (even if they don't know it).
Well, to play devil's advocate, that's 10x in the
context of finding product-market fit. And that
really matters, whether "good" engineers want to
believe it or not too.
"Good" engineering is finding the optimum balance between various competing factors: time-to-market, cost, tech debt, etc.
(There are plenty of "good" engineers who try to perfect everything and never actually ship anything. We have all felt that temptation, I'm sure...)
But I think the core issue still remains. Management can't properly balance these competing factors because they can't be elbow-deep in the code.
I think the "debate" around 10x folks is a bit silly,
and by hard-earned experience, I've learned to question
the motivations of the folks who deny that such engineers
exist
My experience of 10x folks is more like: can you live
with them, will they be a boost to the team overall,
or will they use their 10x to bring down folks around
them (consciously or subconsciously)
But he definitely wasn't the kind of guy you could just throw onto any old team without a care. His 10x did not come for free.
I relate things to Jiu-Jitsu a lot, but here again it helps. I know where I stand in the gym at all times. It forces honesty with myself. There's nowhere for me to hide when another human lets me go from a position that if the circumstances were different they could kill or otherwise seriously harm me.
There are people I beat, people who I rarely beat, then there are a couple people who are so good it's almost like we are playing a different sport. Do I jump through mental gymnastics to make myself feel better about the different sport people existing? No, I look at what they do and try to learn from them where I can while understanding I will likely never be that good. And that's ok.
At seventeen Hussain went on forty-day self-imposed retreat known as a chilla, where a musician practices in isolation until a state is reached in which the music and musician become one. The removal of everyday distractions, combined with single-minded concentration on the practice allows the musician to attain a state of Samadhi or meditative absorption, where one enters into a deeper relationship with one’s own music, and comes in direct contact with the source of music itself. Visions and hallucinations are not uncommon, where one’s musical ancestors may appear and offer encouragement or criticism. What is certain is that the musician makes remarkable progress in his craft. Hussain recalls his first Chilla in Hart’s drumming “I saw things in the music that I had never seen before, new combinations, new patterns”. Six month’s later, against his father’s advice, Zakir was ready to do a second chilla. This time around, the visions were more intense, and Hussain had a premonition that he would soon go to America.
Peter Lavezzoli in Peter Lavezzoli (24 April 2006). The Dawn of Indian Music in the West. Continuum. pp. 108–. ISBN 978-0-8264-1815-9., and this vision came true a year later and Hussain went to America and made a huge successful career for himself.
From : https://en.wikiquote.org/wiki/Zakir_Hussain_(musician)
What most people don't get-- There are not only 100x professionals, it can also be very hard to understand just far ahead they are when it comes to putting in efforts at a scale normal people can't even imagine.
However, many cannot handle the ego damage that results from truly assessing their skill level relative to the best.
One of my favorite guitarists is Matt Bellamy of Muse. His ability to perform is absolutely world-class. I can get better at guitar all I want and I know it barely moves the needle when compared with him. The thing is, the better I get the more I notice in his playing and skills which makes me better understand the full extent of his skill.
If you participate in a sport at a below world-class level where you get an opportunity to meet Olympians who teach clinics in that sport through learning by doing, take that chance because it is possibly the closest you will get to grasping just how wide the chasm is between you and "world class". In my case, the Olympians switched between roles on teams of amateurs they have never worked with before, then switched teams. All while teaching us the finer points of the sport, they would lead the team they were teaching to trounce the opposite team. It was seriously inspiring.
2x engineer is that guy to who you will go when you have exhausted all other simpler options (or go immediately, when you learn to optimize solutions), who will fix or guide you on a level others can't match. And he is probably 2 times more productive with his tasks than median level, or can be, depending on his time commitment. And I think there really can't be more productivity increases above these 2x times. Maybe you can find some unicorns, top of top, who are 3x times more productive, but that's about it.
10x engineer on the other hand is the one who is most vocal about any related or unrelated issues to him, who goes to every smoking break, to every party, to every seminar and tech talk and himself gives talks. He in known across the teams and even projects and the first to be promoted, usually along leadership track. He can also be 2x engineer in fact, but the rest of the "Exes" comes purely from self advertisement.
I somewhat agree with this. I think as people are exposed to different roles and tasks over time, they will take to some more easily or enthusiastically than others, and the skills they build will result in them doing more of that kind of work in the future.
What I find fascinating, however, is that people arrive at things subconsciously in two very different ways. Either it's something they enjoyed at every step along the way, or it was painful at first, but they didn't feel like they had a choice, and eventually they reached a level of proficiency where they enjoyed it and pursued it willingly. These are both thoroughly haphazard ways of choosing what to pursue in life, passively following the path of least resistance like water flowing downhill through whatever terrain happens to be in front of it.
But you can intentionally pursue things that life doesn't put in front of you. One thing people do consciously rather than subconsciously is look at something they find cool and think, "Wow, that looks amazing. I want to learn how to do that." And they don't concern themselves with the fact that it isn't fun at first and nobody is forcing them to do it. They motivate themselves with the end goal. That takes active, conscious effort.
For example, the passive way some people get into web development is that they make a really simple web page with an h1 element containing their name and think, "Neat." Immediate gratification. They change the color. "Cool!" More immediate gratification. And they get passively swept into learning web development.
But there are other people who first get excited looking at a really beautifully designed site on the web. They think, "Wow, that is amazing. I want to be able to do that." So they make a simple web page with an h1 element containing their name, and they think, "This is shit. This feels bad to look at, and I feel bad that I made it." But they struggle through the learning process because they keep the end goal in mind. They keep thinking about how amazing it will be to make something great.
I can confirm.
I have no idea, whether or not I'm a "10X" programmer, but I do tend to work quickly. So quickly, in fact, that I often piss off the people I'm working with, because the job is done, before they have had a chance to interfere with^h^h^h^h^h^h^h^h^h^h^h^h^h^h^h contribute to the project.
You just described something which is trivial to learn in less than one minute. This lack of experience does not directly speak to their skills or abilities.
Extending your example to illustrate its irrelevance, were I to have spent 60 seconds with this engineer alone just before your little ssh test, he would still appear to be a 10x engineer to you.
Focus more on ability and less on what one has or hasn't seen just yet in their careers. I could easily find the limits to your knowledge in seconds and I'm quite sure you could return the favor. I'd gladly hire someone who demonstrates the ability to become a wizard in X and not care in the slightest if they've seen Y and Z yet. I can teach Y and Z to someone like that very easily.
The “ecosystem” of development is very large. I’m sure there are parts of the ecosystem that others would know that you wouldn’t.
I am not able to ssh into any production instance I’ve deployed. I know how I would but it’s just not organizationally allowed.
Maybe this person doesn't quite get how to properly not use a comma between dependent clauses. How could one trust this person to communicate well?
> networking, DNS, firewalls, shell scripting commands, or how to configure the services upon which the application's stack runs, like web servers, application servers, caching services, or even databases...
I have known plenty of gainfully employed, 25-year-old software engineers who didn't have experience with each item on this list. That's perfectly fine; it's easy to teach in one brown-bag lunch session. I'll still take the wizard because those innate abilities can't be taught.
You can teach "networking, DNS, firewalls, shell scripting commands, or how to configure the services upon which the application's stack runs" in a day? This is "Teach yourself C++ in 21 days"-type of stuff.
At any rate, I didn't read that it's not "fine" in TheRealDunkirk's comment. They were just saying that people can have wildly varying skill-sets.
I would say I've been a .1x (uninteresting drudgery, poorly defined goals, toxic workplace) to 5x developer.
The single biggest factor in the 5x instances was a lack of interference. In one particular case, I completely ignored my manager, much to his dismay, and built the system I wanted to. He stopped complaining when integration of new hardware went from weeks to less than an hour.
I don't understand why people demand experience and skills during interviews and then seem to do everything they can to ignore said experience and undermine their workers.
I didn't call you any names. I've also worked in high-functioning teams since before a lot of folks on this site were born. In most cases, I was not the top dog, and there's a good chance that someone else was annoyed by my "contributions." There's also a tiny, tiny chance that I may have had some positive experiences, along the way.
And isn't there a saying, somewhere, about "walking a mile in someone's shoes," or something?
You've got a skewed idea of "nasty". Have a good rest of your day.
I have been working on a project with a bunch of folks, for the last couple of years, that has had its ups and downs, but hasn't had any of that nastiness that was so depressing, in my work life. I now know that it can be better. It's no longer just "wishful thinking." I now have proof. I had to go through a pretty rough patch, to get here, and I don't recommend the process to anyone.
I was sharing that. For me, it's a good thing.
And your post definitely was "nasty," and I was supposed to understand it as a personal attack. It was delivered as such, and was received as such.
Have a great day.
Hence I know that incredibly productive developers exist, but they are also rare since he was the only one that really qualified in more than 20 years of my career.
Because they are rare I don't care how to test for them as it is very unlikely I'll cross path with any when searching for new team members (not sexy enough work) and just try to focus on finding competent reliable people.
The fact is, if you are working for a corporation your salary is mostly dependant on your position and not on your output. Peoples outputs can be orders of magnitude different and they will still be earning roughly similar salaries.
My advice to 10x-ers is: don't work for corporations. If you can be very productive you are selling yourself short.
The most productive engineers are not only good at coding, but also at identifying market value or customer need, and dealing with others to efficiently build everything required for the business.
What it takes to be a 10x is not necessarily the same as what it takes to start your own company, imo.
I understand the reasoning here, but I think it's worth adding a the caveats that:
1. Running a business and programming (or whatever skill you're an expert in) are two very different skillsets, and you need the former to get the best opportunities.
2. Not everyone finds it fun to run a business or take care of things other than what they're actually passionate about.
It may be worth evaluating whether you'll enjoy these aspects, and acknowledge there's a chance you might prefer working for less in a situation with less stress/responsibilities.
Sure. But smart developers are also a good material to be smart in other areas of life, if they put themselves to it.
> 2. Not everyone finds it fun to run a business or take care of things other than what they're actually passionate about.
True. One way, old as humanity, is to find a partner who is enthusiastic about doing the things that you dislike. As far as statistics go, startups have higher chance of succeeding with two founders than one, when both founders have complementary skillsets.
I think that's why there's debate about whether they exist. It's a somewhat implausible idea and they're rare enough that plenty of people have never met one.
However if you follow open source stuff at all it's relatively easy to find examples, e.g. in the Rust world Alex Crichton is an absolute machine. Probably a 20x developer.
That 10x potential matters little if the real hard work is tracking down the right person to reconfigure kubernetes or getting sign off to deploy to prod and the code writing is essentially all plumbing.
Sports teams are the obvious analogy here - with football/soccer you sometimes get these "team of the season" things where the best player in each position is chosen. One striker scored 50 goals for his team, another striker scored 48 goals somewhere else - wow, if they played together the team would have 98 goals. Except obviously not since there's a finite number of chances and the team is structured to play a certain way (often around their star player). And that's not taking into account ego/personality clashes which is a non-trivial concern with high performing people.
I once worked with a 'prima dona' in the team who couldn't stand when someone critised his (average at most) performance.
You only associates both because it's 'easy' to resolve problems with high ego/low- average performance devs, you fire them.. But when it's an high performance dev, it's more complicated..
For most projects/companies? I suspect you probably couldn't get much more efficient if everyone was significantly more skilled, and quickly realise how little meaningful work there is to do there. Given 10 super expert programmers the task of creating another CRUD app or client website and I suspect at least 9 of them would probably quit by the end of the month out of boredom.
Perhaps it's the case that, the less you know about a field, the more you attribute success to mysterious personal characteristics. And the more you know about it, the more you understand the role of circumstance and situational dynamics in determining performance.
I do agree that personal ignorance can make competency look more amazing.
You can ask a carpenter to make a small, simple thing and you will see how competently they use their tools, how steady their moves, how efficient they are with the material. And use that information to understand if they will be good carpenters working on much larger project.
But mostly my coding tests are there to weed out people who can talk but not actually program so that I can save time on the rest of the interviewing process or so that I don't have to fire them in 2 months for no results.
I respect your position. But understand, you are making it tough for me to know if you are good developer or just one of those people who are good at talking their way through interviews or need to go to a hundred interviews to get a job by accident. You will not get hired if I have anything to say about it.
I don't need to hire every good developer. I just need to hire some. The interview is optimised to make it unlikely for a bad apple to come through because it just cost too much to deal with people who are unable to perform. It is very hard to tell if a developer is in fact a good developer but it is pretty easy to spot a person who can't program their way out of a paper bag -- just get them to write a piece of code while you are watching them do it and explain what they are doing. And I also prefer to work with people who are easy to work with -- like people who don't make demands that don't bring them any value.
One definition of stupid is people who cost other people without any benefit for themselves. They are just drag on everything but don't benefit from it. If you come to an interview that I have designed and tuned and start making demands to change this or that derailing my plan and creating no advantage for yourself it is a sign of particular flavour of stupidity, in my view.
Smart people try to find a way to benefit themselves and even smarter people try to find a way to benefit both themselves and others by trying to find a mutually beneficial solution to their problems.
That's literally what interview process is. Because we can't immediately tell who is this person, we need to compensate for it and spend a bit more time with them.
That's why it is called "interview" and not "welcoming ceremony".
This is smack in the middle of what I call a toxic, self absorbed and entitled personality.
Good luck in your life.
plonk
Imagine for a moment if the interview process you describe actually went both ways. Have you ever seen an interviewee demand their hiring manager perform some mock management scenarios for them as part of the interview process? Of course not, because that's insulting and ridiculous. Just as ridiculous as doing the coding interview performance art.
Hiring managers/interviewers often perceive themselves as being in a position of power, which is why they feel comfortable demanding ridiculous rituals of subjugation. It's very jarring for them to not be in a position of power, when an interviewee perceives themselves as their manager's moral and intellectual equal.
“Just hire better, bro”
That’s why there’s a system design round.
To be clear, I am making the distinction between "coding exercise" and "brain-teaser". Brain-teasers are not useful in an interview context, and only result in adding stress to an already stressful situation. Simple tasks like "Write a function that rolls two dice and calculates the position of a game piece as it moves around the edge of a game board" are much better. I am not looking for the candidate to give me their masters thesis in a piece of code on demand, I am looking to weed out candidates that clearly don't have the skills to fill the position.
When you have a team you have hours long sync meetings, communication lag, and middle managers. A single capable individual doesn't need any of that.
The tradeoff is that the resulting code might be unmaintainable in practice. Minecraft is a great example. Notch wrote the complete game largely by himself (with one or two other folks), but now that it's managed by a team and owned by a megacorp, it's effectively rewritten. With 100x more people is it 100x better? Probably not
See for yourself by how much you miss.
Read the quote from Fred Brooks work:
*Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring perfor- mances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and per- formance. (I doubt if that is universally true.)*
There are literally people redefining it in this thread:
> 10x = It takes 10 people to clear the mess they left behind.
> All you need for the myth to be true are a few programmers who will take 10 times longer than necessary to complete a task.
If you want to go fast, do it alone. If you want to go far, do it together.
Unfortunately, I've seen a number of self proclaimed 10x programmers act completely uncollaborative to put themselves in the solo developer situation, outperforming teams of ~5. If management can't recognise what's happening there - they pay someone more than the others to effectively hurt the company.
a) They have never worked with a 10x developer but have worked with terrible people that others described as 10x. If you actually work with a 10x developer, you know what they are. For me 10x is Patrick or Simon or Wendy. They are people I've met and worked with.
b) They can't believe that someone else is 10x better than they are, or their ego won't let them believe that. I believe I'm better than average, but I'm not 10x. I'm not Patrick or Simon or Wendy and that only bothers me at the same level as not being as good at karate as my Sensei.
A 10x developer is the one to identify that the stories don't need to be done at all, if one just deletes some codr elsewhere. Connect the pieces and find better overall architectures. Solve the REAL business problem with a small script instead of 3 new microservices required if one wish to provide enough tasks to work on for 10 devs. And so on.
The test mentioned here is just too low level, a lot of the problem space is already resolved at the start of the test and limited potential for a 10x developer.
Also, because of all the overhead in communication and the breakdown of speed once more than 1 head is involved, it is enough to do "the job of 3" to become "10x", since tasks that need 3 regular devs end up taking a lot longer due to the communiciation effort.
Again, in this test it seems the meetings and communication that slows everyone down by being multiple participants are already completed, assuming everyone did the task alone..
Relevant quote:
"[..] each solution involved simple input, output, modularization, and the use of control and loop logic. Each was the size of one or two small Agile user stories requiring two or more hours to implement. The student recorded time on the major activities needed to complete a solution that passed all required tests, including planning, design, coding, testing, and personal reviews."
- I am familiar with almost all the code at our business and can pretty much jump in anywhere and start working. Most developers try and get themselves comfortable with some small piece and become the master of that piece, but I've pretty actively avoided that. Early it was to keep myself from getting pigeon-holed, but by now I've seen so many different things that I recognize a lot of patterns most people don't, so I can pretty comfortably work on whatever and be productive quickly.
- I leave lots of comments whenever I'm not sure of something so the next person won't be afraid to throw my code away, especially when I'm working outside of my usual area (which nowadays is pretty much all the time). So there are little bits of my thought process spread all throughout our organization.
- I moonlight on side projects regularly and gain experience with other toolchains that way. Because of that I often come up with solutions that are outside the usual ideas that others would normally gravitate towards.
- Once I've got a solution in my head I can really slam some code out.
- In most of my life I'm fairly disorganized, but VERY organized when it comes to structuring my work. I think this catches people off guard.
- I'm routinely the guy who gets tagged to work on struggling projects, and those projects typically have a lot of the same obvious problems to fix. So it looks like I'm being very productive (and relatively speaking, I am), but I'm doing things that are basically routine habit for me that the team in question obviously has not been doing. So it looks like magic.
I don't think any of those things make me special or more able than anybody else. I think it's just a product of the choices I made early in my career to gain as much exposure as I have.
However, as others in this thread point out, the "10x"+ god-mode developer isn't laying bricks faster or with more panache. Their multiplier is in knowing where to not lay bricks, the shape, the structures, the architectures, the pitfalls, the elegant designs. Solving problems in one, that a team might take several shots at and never solve.
As @adamgordonbell pointed out, paraphrased, a "1x" dev is not simply a slower Fabrice Bellard.
For ordinal, we could have homogenous quantity, like meters, so "10X" is really ten times (or the ten means "an order of magnitude by") more productive. Or it's ordinal in that it's numeric in some other sense.
If ordinal, we would have to establish a baseline measurement of what a unit 1X programmer would be. And we know this would vary wildly based on environment, context, and even age. We (the folks in this thread) may agree--other than by personal experience or the Siemans experiment, etc--that there are many confounding factors to just such a measurement.
I think the lowest common denominator we can agree on then would be that there are programmers who are at at least an order of magnitude more <something> (productive) than what we would normally perceive; therefore, 10X programmers certainly exist.
Yet the context of that interpretation depends on the individual, and even by snapshot (maintenance costs did not increase 100X, great docs, mentoring, attitude, etc).
For years I worked as a contract consultant. I'd usually only get called in when projects were in crisis. I'd get into town, solve the problem, explain the problem and get out of town. I've worked in more than 20 workplaces so far in this way.
But... It requires incredible focus and being constantly in crisis mode led me to burn out more than once.
So now I work as a 1 or 2x and just take it easier and no one complains. You could say that I'm retired from my 10x life.
I do sometimes fall back into the 10x mode, cos honestly the rush was exciting and it fed my ego, but I'm trying to no let my ego lead me down the path to burnout anymore.
I find it unlikely that I'm the only person who knows the simple tactic "I will quit if you can't meet this demand", so do you have any more materials to back this up? Or is it simply a feeling (don't get me wrong, clearly that's what I'm operating off too in this arena)
I've been on both sides of this. I've been the hero, and then months later I've heard people say I was the issue.
Obviously I don't know you and I'm not going to tell you to "be humble" or "you might be wrong".
Don't worry about asking me to be humble, it's _taught_ me to be humble, believe me.
I also understand what you say about alternating between being the hero and being the problem.
There is a tightrope to be walked so that you leave your client with code that works for them. I mean some tiny little kernel of code that only you understand isn't going to serve them in the long run.
I'm not claiming to have always gotten that balance right.
So simplistically, we can plot most companies on a boring 2x2 grid management v technical. With bad management (say culture, communication, inspiration as a catch all for management) and bad technical in the bottom left and great management and great technical t the top.
And if you take a person from the top right and put them in the bottom left they will by comparison look awesome.
But no-one on HN is going to say I am a 10x coder because I say
- review SQL stmts and add appropriate indexing - run a profiler over the code base to optimise for hot spots - stop half the pointless reporting meetings so people can actually work - add in test suites (or do the rest of the Joel 12 tests)
But those things will have outsized results, as will fixing product management etc.
Just playing a standard game will have outsized results in some quadrants.
Here's an example: At one company they had a 'financial calculator,' i.e. a program to help visualise how some financial math played out over time and it was giving incorrect results. When I looked at the code I saw that it had been written by composing a lot of those functions you see on actual financial calculators, (1/V, PV, PMT, etc...).
This may have seemed simpler to approach it this way, but because there were so many compositions and there was a root finding algorithm involved, it quickly got out of hand. I started from the problem definition, defined a recurrence relation for what we are trying to calculate, found a closed form formula for the recurrence relation. This part was the hard part.
Now those 3000 lines of FV1P(XYZ(ABC())) turned into like 20 lines of simple math, _and_ the formula could now be solved for the other variables, so no more root finding. I just solved for the other variables, wrote functions for them and that was it. It ended up being faster, correct, numerically more stable, and the code was smaller.
I wrote up a white-paper on how the math worked, included a proof and that was it. It took two weeks.
The value to the customer was that this bug in this one part of their 'suite' of applications was holding up a sale to major prospective customer of their's. So fixing this had an outsized valued compared to the severity of the bug.
Most business / software problems revolve around the problem of getting a person who understands the problem to explain it and work with the person who can write software.
Your example is fascinating- and suggests that it works better when one person understands both parts :-)
Another example I can give is when a client had some process represented by a graph, with boxes and arrows, but the structure of it was really ad hoc. It was _mostly_ a DAG except with some extra back edges they'd added to solve specific problems.
I suggested modifications to their structure, their algorithms and their DB storage for this thing so that it _did_ become a DAG, being careful to explain how to keep their functionality working.
After that the graph could be topologically sorted, and the upside was that instead of loading the whole graph at once as they were doing, we could load a single topological 'level' at a time.
Added an index for topological level in the DB and we were able to make it efficient.
They did have to do some work on the calling side, because they used to load it all at once, and now they had to load it in pieces, but we gained an order of magnitude or more in load time, so it was deemed worth the effort.
Any organisation is a meta-brain, and has emotion running throughout.
Your two examples seem to come after the wheels have fallen off and the magnitude of the problem is evident to all. And they call in a consultant who might see a DAG or (more often I suspect) might see opportunities to sell 120 off shore developers and a rewrite using IBM/Java
But anyway, if you had walked in a year previously with exactly the same plan would you have gotten any traction? A maths heavy white paper explaining why your ideas are the same as theirs but better would have met enormous emotional headwinds.
Maybe our scientific revolution over the past few hundred years is a blip. That does worry me. If better solutions are avoided because of emotional reactions, it costs us all.
Sorry this is starting a lot of thoughts and I should cover them more carefully. thanks for the insight and congratulations- soujds like a fun career !
Nope, most of the time it wouldn't and my experience bears that out ("Let's not boil the ocean...").
Thinking simple, and avoiding premature optimisation, are so often the right thing that we can forget that they don't always work.
Teams and people often prefer to learn the hard way. Mind you _I_ haven't built any companies or startups, and my up approach probably would lend itself to do that either.
There's an adage, by Fred Brooks: "Plan to throw one [implementation] away." I come in when they are ready to throw one away, but aren't sure what to replace it with yet.
As far as it being fun, sort of. First of all I have a more 'normal' job now, second of all it's a rush, and an ego boost, but ultimately exhausting.
Perfect - yes.
The reason ten times programmers don't exist, as programming is hardly ever just about spitting out lines of code. More often than not you have to spend time clarifying fuzzy requirements, getting cross team alignment on requirements or spend significant time on getting your code peee reviewed and build on less than efficient CI/CD systems.
The myth of the ten times engineers is propagated by management. Senior management love to claim they hire the top 5% of the market, something that is statistically impossible.
Maybe not, but I _can_ say that for me the problems I unstuck for customers _were_ about programming, not requirements gathering or process.
It usually was some small kernel of a larger codebase that was ill thought out (usually under-engineered, or solved with a naive approach that wouldn't scale/perform) and hadn't been thought out right.
The solution usually involved recasting the entire approach and solving it some other way.
You are right that I didn't have to deal with town halls, or scrums or any of that, and that was definitely part of the upside.
But what I _did_ have to deal with as a 'fixer' was that I never know what specific skills would be required at this particular customer site. It required thinking on your feet and was frankly exhilarating to pull of.
The code is as solid as houses, yet as flexible as a piece of plasticine.
AI's a heck of a thing but it sure doesn't pin down a definable position very often. Much like with that parent comment, there's this noncommittal quality.
Firstly, do a basic check using https://openai-openai-detector.hf.space/ - it isn’t always correct but it is a strong indicator.
Secondly, it is entirely normal that some real people will have a style that reminds you of ChatGPT. After all, ChatGPT reflects an “average” writing style of real people.
Finally, perhaps reread https://news.ycombinator.com/newsguidelines.html . One word comments are usually a sign of particularly poor form, and many of your comments are a single sentence. That can be a sign of deep insight, but usually isn’t.
That said, I think most of the time the difference between 1x and 2x-5x is putting in a tiny fraction of additional effort. That can be as simple as taking the time to sit down and read all the docs and whitepapers you might get inundated with on a new project as opposed to skimming through and then later complaining about everything being so complex like most engineers seem to do.
At a financial firm I worked at, I spent the first few weeks mapping the code out class by class on a notepad. It was extremely tedious but by the end of the second week I could speak intelligently about how the components interacted (on a massive trading system). For most engineers on the team, there was no sense of intellectual curiosity in this regard. Instead, most engineers I've ever met are very siloed and concerned about their small (relative) slice of the stack -- whether that's a feature, system, or product.
The key to being 10x is your methodology and mindset and that carries over to any experience. I've been 10x at finance, at FANG, in low level dev, and even measurably 5x on a language/stack I had never used professionally and had to learn from scratch (not easy, C++).
I think the key to executing at 5-10x is a careful protection of your most valuable asset, time. By examining how you structure your work, how you approach problems, how you approach "getting stuck" and reaching into areas of a problem that are unknown, as well as how you get distracted, you can find areas that are time sinks.
But in the end, I don't think being 10x is worth it unless it's for your own startup. There's a point in life where, as I said earlier, you get a bit of cynicism and realize you can work at 2x and get just as many accolades. You grow a family and a life outside of work and suddenly 2x is plenty and you can spend the rest on yourself or the people you care about.
To me the intellectual curiosity is inherent, and I don’t think I can, should, or want to tone that down. The best way to protect your time and remain recognized is to work less hours at the same efficiency/capacity, not to reduce the efficiency/capacity. It also helps to have management that is good and has trust in you. This way you can work your 10x style but deliver at a 3x timeline (or whatever x < 10 but greater than expectation) without the pressure to deliver at 10x all the time.
They aren't mythically smart and intelligent and can recite api features off the top of their heads.
No, the 10x programmers I've mostly encountered are "boring":
* They write solid code that's maintainable and relatively bug free. Fixing bugs is an incredibly time consuming activity. A developer who can reduce their bug rate is incredibly efficient not just for themselves but for the entire team and project.
* They aren't going to prematurely optimize in terms of code or design. How many of us have seen development grind to a halt due to an incorrect use of a design or architectural pattern? The worst grievances I've seen are using Microservices when it's not needed...leading to huge slowdowns of productivity due to overhead costs. And that's just one example.
* They understand the value of good software engineering practices that lead to long term success of the product/project/team. Many of those practices are "boring" but are necessary such as writing effective automated tests.
I guess another way to put it, many of the 10x developers I've seen are ten times more effective because they can avoid common mistakes that the average developer makes.
I'll happily sign up as a volunteer. Or in the words of Nelson ‘Big Head’ Bighetti: “Richard’s a 10x-er. I’m, like, barely an x-er. I kinda suck.”
There are people who can kick out an impressive volume of relatively routine work. And there are people who have exceptional structural insight and can use them to make projects simpler, cleaner, faster, and more reliable.
There are also really smart people who complicate projects unnecessarily. And people who are 10X politicians who appear to be doing a lot of work but are actually doing very little.
Any of these could be labelled a 10X developer. But only two are genuinely valuable.
My anecdotal experience is consistent with [CMU's]
research: I don’t know anyone 10x faster than their
peers in solving well-defined programming problems.
But this data highlights why the debate continues:
highly productive developers (10x or otherwise) are
problem-solving at a much higher level. Their
productivity won’t be apparent from a narrow test,
any more than the overall skill of a world-class
football player would be apparent from (say) how
fast they could run the 100m dash.
It wasn't my IQ, talent, or my work ethic that changed.
Rather it was the opportunity.
Note the example cited in the article. This was essentially a greenfield development opportunity for the author, and he implemented an extremely clever and effective solution. He had both the ability and the opportunity. 10x, indeed!
The problem is that those opportunities are hard to come by. Most "software engineering" is just "hey, fix this bug in a big old tech-debt-ridden codebase" or "hey, implement a new feature in this big old tech-debt-ridden codebase."
You can take the most talented and motivated developer in the world and they won't be 10x in a situation like that.
From TFA, the dev interpreted the goal as "have all the tests" rather than "write all the tests." And then determined that it would be faster to meet this goal by building a tool to write them, rather than writing them individually by hand.
But, the true cost of software is in the maintenance. Building the software is 10% of the cost, 90% is the cost of keeping it running and fixing it over the life of the software.
Certain programmers will "make" software that might be only, say, 0.7 times as fast as the next. But, the way they made their software will lead to 10x more software maintenance. IMHO, this would be a developer with poor design patterns, no regard for automated testing, and no regard for how their work can be used and modified by others. It'll work, and it'll get "done" within the sprint, but the true cost will be seen in the years that follow.
Those 10x developers are causing the maintenance costs to go up by 10x. If you believe the numbers around 10% to build, and 90% to maintain, then that means one of those developers will make your project cost almost 9x as much over the life of the software.
That's the 10x programmer you should be watching out for.
I think the peak was implementing cracklib based password strength checker that... just returned that password is strong if cracklib was not installed, and didn't tell ops to install it on servers or add any check that would alert if it is not installed.
> Those 10x developers are causing the maintenance costs to go up by 10x. If you believe the numbers around 10% to build, and 90% to maintain, then that means one of those developers will make your project cost almost 9x as much over the life of the software.
On flip side, developer making right architectural and maintenance decisions might just be 10x in grand scale of project, even if they don't write code all that much better or faster than coworkers
I'd like to see some data on how many of them have a backlog of 18 poorly-specified JIRA tickets per 2-week sprint and daily one-hour standup meetings along with two-hour weekly "retrospectives".
What I think people react against is the idea that it’s some magical intrinsic thing. It’s not. Like anything else it’s got a component of aptitude but the rest is lots and lots of learning and practice and “getting into the craft.”
A 10x programmer is the product of talent, discipline and environment. Same as a professional athlete. The environment is what differs.
In professional sports, the athlete has a team supporting them to maximize output (coach, doctor, assisant, etc). They are free to focus on their art. Talent and discipline then make the difference.
In software the programmer is at the mercy of the product manager, other developers, management, etc. Because software is more than code, the time they spend on improving their talent is interrupted by meetings, compromise and whatnot.
In my experience, 10x programmers are usually entrepreneurs in startups or intrapreneurs in larger companies. They are supported by their environment to allow them to shine. This allows them to focus on their talent and frees their time to code, learn and improve relentlessly over time.
For example - I see optimization abstraction as a core skill, searching for the best performance given the least amount of resources (whether developmental or computational) and what seems to be a familiar pattern.
Tooling agility may be another, i.e., how quickly can one re-create a cookiecutter build environment with observability, tests and release signing given a blank slate.
Package creation might also be a thing, though it is an example of optimization abstraction.
Troubleshooting skill sets follow from experience and understanding, and, frankly, some creatures are better than others in this regard.
Lines of code (LoC) used to be a measure, two decades ago; these days, compactness, certitude and conciseness may be the golden ticket.
Is the baseline the average developer worldwide or the average developer in any particular team?
Are we measuring jira tickets fixed or net profit produced for the business, or the impossible-to-measure “productivity”? Are we measuring a single task or consistent performance over years?
The anecdote in the OP is about a developer solving a task in a tenth of the estimated time. Great, but this seem more like an issue with the estimation process which presumably didn’t involve the devloper. Would an unrealistically low estimate mean they were a 0.1x developer?
Most of the issue with the 10x developer as a concept is (involuntarily) summarized in this quote: 10x developers don't exist, merely because 10 times is a lot! World-class athlete don't run ten times faster than anyone, and a F1 can't drive ten time faster than a cheap car. In most competitive situations being just 10% better than the competition will make you win most races and earn most of the awards.
Do 2x programmer exist, probably, but that's about it. Or you can call then 10x if you want, in binary ;)
The situation we find ourselves with software has very little to do with the actual developer effectiveness: I've never witnessed a project that was slow to deliver because one developer was too slow, it's almost always organizational and management issues that slow down development teams. A poor developer in a functional team with good leadership will outperform a rock-star in a dysfunctional organization any day.
Are there people who are 10x better than others at a skill? Obviously. This is blatantly true in every human pursuit to ever exist. Why is the idea that som individuals are 10x better at this one skill than other individuals so mind blowing?
Programming isn't unique, it isn't special, its just a skill like anything else, and like anything else there is a variety of skill levels.
Whether there's any fundamental truth doesn't much matter, everyone wants to bend the idea to fit their own agenda.
My first exposure to the term were meme type descriptions that seemed to describe 10x programmers as fast, but also implied a lot of negative qualities, anti social, no time for meetings / communication / documentation.
I thought it was a joke meme making fun of very fast but ultimately flawed programmers…. but then I realized some people were serious and sorta glorifying the negative aspects as well.
The core argument of the blog post was that focusing on things like scrum vs agile and different testing methodologies and programming languages etc doesn't matter anywhere near as much as the actual programmers you hire. Hiring the right programmer will have 10x impact on your overall productivity compared to choosing the right project management or testing methodology.
It def wasn't about some guy on my team rocks, but about this company over here does better work. That meaning isn't really how its used now though.
The study was "Programmer Performance and the Effects of the Workplace"
It's older than the study you're referring to ( https://dl.acm.org/doi/10.5555/319568.319651 )
So chances are you've never seen one. Now I wonder how are our experiences so different, because I've known a bunch and I've worked at that level sometimes.
> I thought it was a joke meme making fun of very fast but ultimately flawed programmers…. but then I realized some people were serious and sorta glorifying the negative aspects as well.
That makes sense because there's a lot of egos involved in this topic. When you are doing most of the job of the team, obviously you're tempted to make it a part of your identity.
But also it makes other people jealous and they look for a way to justify, blur, compensate and explain it away. In this matter, denial often comes from insecurities. Some of the incarnations:
- There aren't 10x programmers, it's just because sometimes 1x programmers are surrounded by 0.1x programmers.
- 10x programmers generates 100x maintenance when they leave.
- There are 10x programmers, but they're not you, only a handful of geniuses in the world.
- There are 10x programmers, but they're jerks and a company is better off without them.
etc. (Sometimes the criticisms are justified, but not always)
If you've never seen one, maybe it's because:
- You're working in a line of work that deals with solved problems, incremental solutions.
- You're working in a process-heavy team. Either 10x people flees from that or the process makes them invisible.
- Other perverse incentives.
No I don’t know what people mean.
I’ve seen very productive developers, but it doesn’t fit the “10x” that I’ve seen described.
But once the mechanics are known and the pitfalls are spotted, the difference should be much smaller, provided knowledge is properly transmitted through documentation, pairing or whatever.
Actually, a wise boss won't put the 10x programmer to work in parallel with the rest, but some weeks ahead, as a minesweeper.
Edit: another area in which some programmers are much better than others is bug hunting. But again, there's a moment when every evil schrödinger-ish bug is fixed.
Furthermore they tested in an academic environment on simple assignments designed to take an hour or two. It's impossible to do all the required steps in 6-12 minutes, so this experiment could never show a 10X disparity.
I've worked with two different people whom I would consider 10x programmers and I might even go so far as to say they were 100x or even infinityx programmers because they just created solutions that a team of normal programmers wouldn't be able to come up with even if they were given the rest of their lives.
Similarly, 10x people exist in other fields.
For example, there was outrage at Fusion (a journalism outlet) in 2017 when it was revealed that Felix Salmon was being paid $400,000 as a financial journalist, whereas other journalists at Fusion were being paid $60-80,000.
People made comments like "Fusion could have hired four Harvard graduates with degrees in Economics for the money that they're paying Felix" -- but neglected to consider the fact that Felix Salmon has such a profound grasp on the way markets work and is such an original, grounded, intuitive, and counter-intuitive thinker that you could not replace him with ten thousand Harvard graduates. He simply has singular insight.
I don’t have data on it—it could be hiring or compensation—but I suspect it’s simply systems of work that spend more time focusing on the right problems, in the right way, without slowing down the work.
I'ts not just about systems.
For advanced stuff, the difference is not 10x. It is infinite. Some people would do it well, some poorly, and order(s) of magnitude longer, most - not at all, even if they put decades into that.
Think: how long would a regular software developer take to do John Carmack's work on Wolfenstein and Doom?
People are debating things like "10x isn't actually always 10 times the output" and "it depends what the context is and what the short- and long-term goals are when deciding if this person is doing miracle work or just making a mess for the future."
If we said, "there exists people who are, in many contexts, just naturally very fast to come up to speed and stay up at speed" I don't think there'd be a debate. We aren't labelling a specific context or speed, but we all know people like this exist, by very nature that not every human is equally as good as every other human at everything, and outliers exist.
It seems to play out well in the teams I've been with too. If you have 9 people on your team, 3 will be responsible for half the work. If you have 25 people, then 5 will be carrying half the weight.
Extrapolated out, on a team of 100 people, 10 will do half of the work. That would mean 1 of those 10 will be doing 5% of the total project while 1 of the remaining 90 will be doing 0.5% of the total project.
Thus, I believe you can say that 10x developers exist, but only at the large team scale.
For any project that's sufficiently large, say more than 20 people, what one needs is someone who's contribution helps to make everyone's work just by a bit - say 1.1x programmer, but where the 'x' is the productivity of the entire team. They would do this by making correct & timely decisions on architecture, clearifying interface requirements and identifying gaps & errors early in the project.
The same can be said of tooling and major OS programmers.
The work of devs like Guido van Rossum created, Linus Torvalds, Ken Thompson David Moon ,Richard Stallman and many others is so multiplicative in terms of economic value output that a single order of magnitude doesn't come close to describing it. It's probably more like two or three orders of magnitude.
Bill Joy used to say that the # of smart, effective people in an organization = log (total # of people at organization), AND the only thing Management can do is slightly adjust the base of that logarithm.
Like can we all just accept that people have different capabilities and move on. That despite vast differences in abilities among people, for most tasks, there is an acceptable minimum ability that a lot of people reach.
So the question is less "Do 10x programmers exists?" and more like "Do we even need a 10x programmer?"
I explain this a bit by means of a simulation in this video: https://www.youtube.com/watch?v=3Ea3pkTCYx4
Since 10x'ers (by defintion) are rare, most leaders / managers should be trying to build 10x teams. That is, the whole is better than the sum of the parts. For example, a team of 5. As team members, at any given moment three rise to 3x, one to 1x and the fifth is neutral. Something like that.
10x does not exist. It is overblown. Yes, there are extremely gifted people- no, they are not 10x their peers.
Rather than leetcode tests you can review the technical skills of your peers. I want it to be richer than endorsement on LinkedIn but a proper evaluation of the achievements of a peer.
If you don't use GitHub it might be a struggle but I would love to be evaluated by other developers.
I'd be betting more like 99.9th or even 99.99th percentile would be more like it.
Whoever could replace other's manual process by one time automation tool, it's 10x developer.
It's not about your "super design pattern".
Does anyone else find this statement triggering?... I feel like 90% of the things I solve that others can't or struggle with are not "well defined problems" which is why they are hard to figure out.
If you're ever on a team like that, it's just a joy.
I will never understand the specious metric that we call 'productivity'. Outside of a production line, what the hell is a 'productive' developer? Yes, I know you can choose many options for measuring that, but therein lies the problem.
You can try to cultivate good ideas. But it’s not like we’re going to see the 100m dash of good ideas. Most of them only turn out to be good ideas in hindsight. A good number of times you might be sitting on a good idea and everyone around you will be telling you what a bad idea it is.
Only time tells.
Take the Infocom example from the article. Who knew, at the time, that Z-Machine was going to be a good idea? Did Berez and Blank have a crystal ball that could see the future of the company? They might have only been able to develop the Z-Machine because the company was only a handful of people and they didn't need to work too hard to convince anyone. It wasn't a big company. How does that make any of them 10x more productive than "regular" programmers?
With what few empirical studies we have it doesn’t seem likely that there are, “some who are simply gifted.”
This is just argument by assertion. You would still hope someone would demonstrate the existence of 10x programmers. A lot of these one-off anecdotes in the comments are closer to 1.3x to be honest.
In our industry there are plenty of very weak developers, I bet you have worked with someone who is 0.1x of someone reasonably good, even someone who makes a net negative contribution.
When I hear 10x programmer I definitely don't think "that they are 10x more productive in grinding jira tickets."
I think there are programmers who can build something that would take ten or more other developers to replicate.
And that's "easy" since some people can win by choosing the right game to compete in.
they'll procrastinate on them because they are boring and tedious and will go work a massive project instead because it's fun to them.
they'll finish that massive project in the time everyone is fiddling their thumbs with the stupid back and forth of the meetings and whatnot of those "tasks".
if you are lucky to get one of us, let us run free, we'll make you some really cool shit without any input.
if you stifle us and try to fit us in a box, we won't make shit. we'll eventually get bored, pissed off, and leave.
oh and don't touch our code, it's beautiful, and it's the only way it'll work, trust us! ideas welcome, code not!
we don't like teams. one person, one thought, one architect, one vision, one program.
source: am one, believe me or not idc, i prefer being mythical.
Hope this is satire. Otherwise its a horrible idea.
you negged and put your opinion down, but you forgot to put down why it's "horrible"!
so, until then... yes-huh!
eventually the 1x teams understand the system and mimic the patterns.
enough patterns created by the 10x it's hard for the 1x to fuck things up.
yes you eventually won't have the 10x one day, but if you utilized them right, they made you a nice temple.
10x or not, if you have a team design a system you're doing it wrong. teams can work in it later, one person should design it.
feel free to shoot me a way to contact you if you want.
but it's not really worthwhile for me to basically gather up a resume unless you have connections.
a lot of the cool stuff in my later years is commercial.
you could have just replied with your contact info if you were really interested in me.
the only reason for me to try to prove anything to you would be if you were actually someone.
This idea of a surgeon team is also from Brooks.
but that long topic aside... i was just pointing out the ideal environment for "10x programmers".
you put a 10x on a team and treat them the same, they become a 1x (or worse because they are bored and procrastinate), the others will drag them down to their level.
to make teams work, let the 10x design and develop the initial system solely. then the 1x work in a scoped domain (using a plugin/extension system etc) within the 10x's vision
i don't need an e-diagnosis from a few sentences of mine though, thanks.
i know what i make and what others make and how easy it comes to me. the label doesn't matter.
i tamed my mind and my environment long ago, any thematical "adhd" attributes concerns me not...
my sake thanks you for your hope though.
But they won't work for your company.
So, stop talking about it in your interviews.
I'm more of a gordian knot cutter than a programmer.
I see you didn’t say “we gave them money that they could put in their bank account that they could use to support their addiction to food and shelter.”
Yes, RSUs in public company can lose value. But at least I can and do sell every six months at vesting a diversify.
And only 1 out of 10 startups “succeed” and by “success” that means the investors get their money back, it says nothing about how the employees fare.
I LITERALLY said "bonus position in addition to being paid the same as me" .. so yes, I did say "we gave them money they could put in their bank account".
Take this rant somewhere else.
Giving them “a raise” or even “a large one time bonus” would have been “literal”.
I have no idea who you are “being paid the same as you” could literally mean anything. Was that a 10% raise? Is he getting 10x more than the average developer? How does his “equity” compare to the founders? The investors?
“Getting paid the same as you” also could mean he gets paid less than the average SWE II at any major tech company.
“literally” your reply doesn’t say anything. I’ve been contacted twice about a “CTO” position in the last three years by sone unknown startup that was offering me less compensation than I make as a mid level cloud consultant working remotely at $BigTech. (I have a great network locally).
I have no illusions of being “10x”
I get paid more than enough, but what I look for is to be able to spend 40 hours a week having a blast.
it's not 10x in SLOC or whatever, it's total, long term, value. and yet it does exist.
it's like arguing that Michael Jordan doesn't exist because everyone you've ever played with was only about as good as you.
Of course it would be nice if coders that rare were paid like pro-athletes...
The -0.5x developer is not a myth.
This happened because Siemens AG and Ericsson entered a joint venture called Ellemtel. It was required to produce a software product in 6 months. Each sent 500 engineers. At the end of the (successful) project, fully half the code was found to be authored by one engineer.
The contract was such that, without delivery by deadline, Ellemtel would not be paid. Without that one engineer, the project would have failed.
Details... He was responsible for assigning tasks. Tasks were two weeks. If a task was not done by the two-week deadline, he did it himself over the following weekend.
They took blood samples, periodically, to measure stress hormone levels. Stress rose as the deadline approached. It took 2 years to return to normal. (I.e. burnout is objective.) The 500x's stress level did not increase.
(On a later project, involving an OS kernel he wrote, he did have stress. Also, for English-speakers: Siemens is pronounced "Zeemanss".)