They caveat it with “well defined programming problem.” That’s the myth.
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.
I think it’s more than being a reference book, but really understanding at an intuitive level how things work and being able to explain it. They are facile with the concepts to such a degree they don’t have to think about how things fit together to use a system and language and sdlc, they are able to just focus on the specific challenge. Further they can unblock everyone around them by providing that intuition on demand, and often explaining concepts others struggle with in a way that gives them a similar intuition.
I think there are even people who are 10X as fast as others at solving well-defined programming problems, aka grunt work. Those who sit down and grind through it with a highly optimized workflow and don't take many breaks.
Ya i think this comment nails what i consider to be a 10x programmer. They aren't people who solve things quickly. They are people that solve things quickly and also enable their team to solve things quickly. They feel a need to not only be efficient themselves but enhance the efficiency of their teammates through mentorship, teaching and team awareness/empathy.
Yup. Concur almost entirely. It’s superb abilities in complexity management. Which is what real software engineering is all about.
Like management or raising kids, everyone think they can do it.
Very few can do it really well.
The 10x programmer doesn't exist. Yes, an experienced programmer can complete a well defined coding exercise, in their field of expertise, ten or more times faster than other programmers. There is research to back up this claim.
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.
This is opposite in every way from my experiences above, including my direct experience being one. Especially the “rely on the team” - I think you’re confusing hero programmers with 10x programmers. Hero programmers leave husks of teams and shoddy code in their wake as they rampage through a career of self interest. A 10x programmer is a force multiplier for the team and spends their energy unblocking the team and driving a high standard for quality and ease of improvement. That’s essentially how they accomplish 10x the work, even in their own work. Because the team functions well around them friction to effective productivity is much lower.
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.
There only a few John Carmack and Linus Torvalds in the world, just as there only a limited number of opera singers compared to regular singers. The suggestion is that 10 times programmers are much more common than that. This is a more modern scientific article dispelling the myth of a 10 times developer
nope, sorry they absolutely exist and 10x may easily be an understatement. now, the conditions must be right - you put a 10x embedded system software engineer into a java microservices job, in a couple weeks he might be a 2x. You make a 10x engineer go to 37 hours of meetings a week, you get a 0.05x engineer (along with everyone else on the team).
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.
So that means one engineer can do the job of ten? Unlikely. It is even more unlikely that person is working in your organisation, unless you work in one of the FANG companies.
No, they are 10x as productive due to a confluence of abilities. But they typically achieve that by being a force multiplier and unblocking the team in various ways rapidly.
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?
there are problems that people solve that you could pick 10,000 average engineers and they'd never solve. if you have the right person and the right problems why not?
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.
For every legend there are many many that don’t accumulate fame enough to be observed. The legends as you say exist, therefore the distribution width is at least as wide as they force it to be. The variance is small, but the distribution is wide.
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?
we don't really know the width of the distribution of course! and it depends on where you are and what you are doing.
"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.
Well, that’s the trick isn’t it? A 10x engineer does that. Because you may not doesn’t mean no one can. A large part of my successful career has been built around my ability to intuitively discern the essence of the challenges my customers face and proposing then implementing novel solutions to it. I don’t know how I do it, but I do. I’m able to enlist my teams to a productive and useful way, cut through blocking issues rapidly, and (when I was writing a lot of code) implementing clean solutions that the rest of my team were struggling with. The 10x doesn’t come from writing 10x the LOC, it comes from writing the right 1 line of code 10x faster than another engineer, and finding ways to make your team around you 10x more productive. I’m sorry you’ve not had a chance to work with folks like this. And you are right, they are in top employers because they are valuable, and are over represented in FAANG. And they are extraordinarily rare, and as such are extraordinarily expensive. But rarity doesn’t imply impossibility.
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."
Important to note that in your example and in software engineering, the 10x "skill" is not something measurable by "output". The 10x myth is mired in the fallacy that a 10x'er can develop a product 10 times faster. Fred Brooks-esque principles are still constraining.
It's possible for someone to be 10 times more capable of diagnosing problems, but they don't fix 10 times as many cars.
The productivity difference in software engineering (tackling real-world projects) is vastly greater than 10X. We are flush with stories of teams that burn through huge sums and completely fail to deliver a working product. Delivery vs nondelivery is ∞X.
The big difference is that the Mechanic has to manually do that for every single customer, where a software 10xer identifies a crazy hard bug once and fixes it for all 10000 customers at once.
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
Mechanics would have to file tickets with the car design team :)
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.
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…
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.
You know better than the person telling the story, I find that beyond amazing.
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.
I feel like I was a 10x when we did monoliths. With "fake team microservices" - which is extremely prevalent these days, I feel like a 1x developer. The second I have to open another repo and do something - pull, yarn, build, and start updating, push, go back and update. I just lose all want to do anything for this company.
"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.
The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment. Runs the application locally? Run tests locally? lolno, we're Modern dev-ops™ so you push it to CI and wait for 10 to 30 minutes and browse HN in the meanwhile!
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.
> The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment.
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?
I've never worked anywhere that was deeply invested in microservers and had a workable development environment.
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 (
> It's not "on me"; I joined long after all of this was set up.
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.
I have not talked to anyone before – including many enthusiastic proponents of microservices and some developers of things like k8s that I've met over the years – who claimed that the operational story of microservices was "basic" or "trivial". It's widely recognized this can be complex and takes time to manage well. Is this worth the trade-off? Opinions clearly differ on that. But the trade-off is very real.
> 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.
> I have not talked to anyone before (...) who claimed that the operational story of microservices was "basic" or "trivial".
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.
Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase.
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.
> There is absolutely no reason to split the codebase
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.
> Exactly, microservices make things unnecessarily complex and are often just a poor way for a team to avoid implementing design patterns, namespacing in a codebase.
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.
> Microservices are a solution primarily to an organizational problem and secondarily to the problem of allocating and managing computational resources.
"A" solution does not mean the only solution or the best solution. They're often treated as the only solution though.
> "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.
What problem are you solving with microservices? Scaling? You can run the same service everywhere but route traffic to specific endpoints to pools of the same thing. These are devops problems and don't necessarily need to be reflected in the code.
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.
> What problem are you solving with microservices?
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.
I would agree with you that it could be useful for organizational problems but I would resist this as long as possible. In any case, I prefer to not split engineering teams but for practical reasons (e.g. keeping onboarding times into the team reasonable) you are quite forced to do so.
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.
The GP of this discussion talks about 10 devs where each dev is working on more than one microservice. I've seen a lot worse.
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.
What exactly is the problem with a "massive monolith in a monorepo"?
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.
> They are often, and by far, the best solution though, specially taking into account the tradeoffs of whatever alternative you come up with.
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.
> 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.
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.
Software engineering, tools, and practices nowadays seems more concerned with enabling higher headcounts than it does enabling existing members to work effectively.
Its just that you moved from an environment where you knew the product back to front and how everything fit together really well to a new environment that you understood less.
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.
Being able to work on both the client and the server side at once is worth at least 5x, since you're not at the mercy of somebody else to get things done from end-to-end.
Docker Compose has been amazing for working both client and server. An image for Postgres, another for Node.js (for example), and it's (almost) off to the races.
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.
Microservices for their own sake seems to be a mistake. The big win of microservices seems to be when your dev team is big enough that coordinating everything within a monolith becomes cumbersome. It's more about organizational structure than anything else.
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 choice of architectural solution is exactly where the developer can achieve their 10x gains. So who knows your monolith idea might achieve the 10x gains over whatever solution you're currently stuck with?
Motivation and passion are very much underestimated in performance. I hope you manage to rekindle your passion somewhere else and run at 10x the speed again!
What if you described linear algos as being 10x faster than quadratic ones?
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?
> ...suggesting that I could build ffmpeg and qemu the same as Fabrice if I was just given more time.
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 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'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"
Agreed. Playing with other languages for fun, even just for a very short time, really helps make that divide clear. Especially languages that are very different in some significant way than what you’re used to.
For building things I find that that “skill” to be powering through uncertainty. Some people are constantly in analysis paralysis and it is a struggle to watch them code something that isn’t completely outlined.
>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,
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
This is a good point. If people used 10x to just mean: 'this person has a different magnitude of skill in a game changing way' then the term makes sense.
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.
This makes it sort of trivially true, though. Our scale of what skill looks like is naturally normalized to typical human capabilities, and “much” is a a point on that continuum.
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.
I've made the analogy before that there are tasks that are like walking, and tasks that are like weightlifting.
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…
This is a much more meaningful litmus test for extreme capability.
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.
Not to mention the devs who can look at a problem and say, "Software isn't the right solution for this. Let me give so-and-so a call and we'll have this ironed out in 5 minutes."
10x exist in most fields. In academia there are definitely people who are heads and shoulders above others, for example. Then it is also a matter of interpretation, what is meant by somebody who is 10x:
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 do agree with your opinions and I’ve met 10x programmers who are also nice people. But I think there is resistence to the idea of 10x and a natural sympathy that 10x is a myth because of a few types of 10x
- 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.
Severe ADHD, uncontrolled for 30 years until recently.
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.
Why do people take some idea and totally botch it?
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.
I disagree that a regular 1x programmer is comparable to someone slacking off on a university group assignment. I prefer the sports analogy, where there are some stars with disproportional impact in the outcome of games, but who work with other also very hard-working, professional athletes. No one is slacking around, there is just some people that are better.
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.
You are not botching my idea but Fred Brooks idea:
*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.)*
To me the concept doesn't even have to mean that individual is outputting 10x amounts of code or closing 10x stories...
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.
Bingo. 10x is not about how fast someone codes. That is why there is confusion here. Of course someone cannot write code consistently 10x as fast or write 10x as much code. On a regular basis? That is nonsensical.
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.
Having five 3x programmers on a team is likely a more pleasant working situation than having one 10x and four 1x programmers - also, slightly more productive! I wonder which arrangment is harder to create?
My reading is that some hold a belief that the distribution of developer productivity/skill is not a Normal Distribution. Yes, in a normal distribution some on the right will be 10x those on the left. But as I read it, the “10x” advocates propose there is some sort of Guru Spike on the right hand side that’s specific enough to the realm of development to create a meme from it. I harbour skepticism that it’s anything but a normal distribution.
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?
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 [...]
Yes.
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.
> fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks.
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
This has been my experience and the experience of many peers that I've heard from. Admittedly, there's an inherent selection bias there... people dealing with frustrating situations are certainly more apt to speak up about them.
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.
or is it ? some code is made to be long-lasting (and that's the one we "see" because of course it lasted long already) but the large majority is short-term projects which are only relevant for a few months / years and will never get reused afterwards.
Hah, yeah, I think we haven't a terminology difference here. I wouldn't even term "bad" code in short-lived projects to be "tech debt" in the first place.
I definitely agree you about the near irrelevance of tech debt in short lived projects.
the large majority is short-term projects which
Is this really true? Really depends on where you work, I guess. It hasn't generally been my experience.
But it really depends on if you're working at e.g. an agency vs. working on long lived in house projects.
I've known all 3 of the enumerated types. I'd suggest a 4th to add in.
- 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 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 (they run fast and break things and leave to others clean what is broken, which is part of the reason that they are fast).
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.
You're hitting on the most frustrating aspect of this argument, the sometimes bizarre imaginary scenarios to try to make 10x a negative instead of a positive: "what if they're a 10x programmer but also a psychopathic serial killer who targets their colleagues!?!?!"
I think the highly productive programmer who ships features like crazy but leaves a trail of garbage in their wake for others to clean up is actually the most common archetype I’ve seen in real life.
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.
> I think the highly productive programmer who ships features like crazy but leaves a trail of garbage in their wake for others to clean up is actually the most common archetype I’ve seen in real life.
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.
Yep. I’ve noticed that the term “10xer” gets used in both the sarcastic and the serious sense, and it’s important to keep the archetypes and characteristics separate. I tried to clarify in this old comment:
While what you are saying is true, sometimes 10x is 10x. They push that feature and it secures an investment round. They push that feature and it secures an important client. They push that feature, don't commit it to the main branch, write tests, commit tests to the main branch,and help the team kill that debt over the course of a few months.
- The one who is <INSERT ANY RATIO, EVEN NEGATIVE> at the expense of their colleagues
- 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 10x jerk is a really common trope that's thrown around every time the 10x debate comes up anywhere in technical circles. Truth is while they exist, not all 10x are like that.
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.
But it takes two to tango. In my experience a lot of the negative impact of a 10x:er is actually that they make 1-3x:ers feel very insecure, and some of them can’t handle that / go off the rails…
That has not been my experience at all with "10x" programmers. I have often run into the first type from the parent comment - "hyper-productive" people who churn out huge amounts of code without a lot of thought. They tend to leave side effects all over the codebase, and often have someone in management who sponsors them (hoping to ride to promotions as a pair) who forces other teams to carry the burden of cleanup. However, if you run a startup, this kind of person really is an amazing asset, because there isn't a lot of codebase to clean up.
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.
I’ve seen it many times. I’ve even seen managers on teams try to sabotage a 10x:er because he made the manager (and team) look bad.
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.
Do you think 1.5x people get paid 50% more than a 1x typically? If a 1.5x got paid 50% more for doing 50% more work, do you consider that disproportionate?
Fully agree. Will say that although the third type may be great at delivering value, they may have a negative effect on the team and either drive away talent from the team, bring down morale, or cause the only people to stay with the team to be less ideal (since some great team members may see the toxicity, and understandably avoid that job)
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
10x just throws people off, when it's really just much better 5x-10x-100x. Also, it's often hard for people to accept that someone is demonstrably better at the same job.
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.
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.
I think your 3 examples of "10x programmers" definitely exist.
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.
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. It's just that the kind of person who does that is also likely to be burned out, and have nothing else going for them in life, so they tend to become an asshole – leading to your assessment of things.
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.
Well said. It definitely matters.
"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
Haha. I usually question the motivation of those who say that such engineers do exist. However, that's because they usually fail to consider any of the nuances (team fit, luck, circumstance, etc). You definitely do not fall into that category; I think you really describe it well.
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)
Amen. I worked with one single programmer in my life who was perhaps a true 10x. However, he was a lot. He was very hyperactive and on the autism spectrum. Social grace and norms were totally alien to him. He really crapped on other programmers. However, he was actually an extremely sweet person at heart! Just lacking in the filters and restraints that neurotypicals have. We eventually reached a good working arrangement where he could be his eccentric 10x self and a mortal 1x peer engineer like me worked closely with him to gently rein him in in ways that would have been impossible for management. For a couple of years there I thought we were a really good team.
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 have seen it. The person was a new hire, and while he's a solid developer, from a maintenance / debugging / support perspective I haven't encountered his equal -- he solved a complicated issue in about 4 hours (including the time taken to get the dev environment setup) and apologized for how long it took. Great attitude, and amazing ability to get at the root of maintenance problems.
In my experience, there certainly exists a 10x gap between those who aren't very helpful and those who are extremely helpful. That is the crux of the research as I understand it anyway: You'll find a big distribution in talent, but a median producer is not 1/10 the best.
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.
> You'll find a big distribution in talent, but a median producer is not 1/10 the best.
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.
We had one 10x developer in our team (it was a bigger project with about 70 developers). His output was 10x the average mainly because he had very (both) deep and broad domain knowledge, i.e. knowing largest part of our own code base. That will allows him to produce much more, since he doesn't need to investigate how something was done or how to integrate the new feature into the system. He was also quite hardworking, which also helps.
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.
> 10x exist in most fields. In academia there are definitely people who are heads and shoulders above others, for example.
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.
Well, it might simply be "push the project architecture in right direction so whole team overall is efficient".
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
> You shouldn't concern yourself with how high you rank in this hierarchy.
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.
Every person believes oneself to be a >1x in everything (dancer, global policy thinker, lover, ...), that's normal and that's how our brains are wired.
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.
In any field where there are multiple possible directions for optimization 10x can be in many different directions.
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.
I think that of all professions, even creative professions, best-selling fiction writers are the easiest to compare in terms of $$$. How does Saint-Exupery's Little Prince fare in total lifetime sales compared with Stephen King's entire output? (I don't know! But it's a question that can be asked).
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.)
Is money really a good indication of someone's skill as a writer? That's its own question, and I guess it depends on what you consider good or not. There are plenty of authors who become millionaires/billionaires because they knew what the market liked and how to sell themselves/their work, but many people would not consider them the pinnacle of their craft. It's undeniable that something like Twilight or 50 Shades of Grey is extremely successful, but whether that makes Stephanie Meyer and EL James better authors than Stephen King or George RR Martin is debatable at least.
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 personally believe most people reach their optimum lifestyle subconsciously
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.
Beautifully put! I just realized I've been on both sides of that. Younger me tended to be the first case you described. Older me seems to tend towards the second case. Perhaps because I am highly conscious of my time now and don't give myself much time to play.
Or maybe another way to look at productivity and effectiveness is that there are the ~1/10 performers and top performers at 1 x, of which in most fields there are very few, but there are lots of 1/3 … 1/10th performers.
Yep. I have 10x weeks - sometimes months. Then I have weeks like this one where I do basically nothing.
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.
Ah, the times where I worked for a large org and could get away with these variations. Startups and consulting clients can't afford or don't care that you're having a bad couple of weeks.
I think there are two categories of IT engineers (to include not only programmers). There are 2x engineers, and there are 10x engineers.
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.
An economics way to look at it would be to consider marginal output of the worker, ie how much value/profit/whatever_you_target the organization would have produced with the worker minus how much it would have produced without the worker.
> 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.
> I think 10x developers, like world-class athletes, musicians, and authors, absolutely do exist. You’re just not going to find them with a coding test.
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.
I consciously reduce my output to be at about the 70th percentile of whatever team I'm on, with short bursts of max productivity when I subjectively feel like it will help the team get out of a pinch. People like me a lot more this way.
Being seen to be labouring away also becomes important. Punching out 3x others, while working regular hours against visibly "harder working" people - leads to a reputation of being lazy.
because the job is done, before they have had a chance to interfere
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 concur. I've demonstrated that I'm a 10x+ full-stack programmer several times in my career, but I've met at least a few people who could bang out code better than me. I can design complicated systems with many moving parts to solve difficult business problems, and hand them off to someone else to manage with minimal maintenance. I've done it many times. However, I worked with one young guy who understood Ruby better at age 25 than I ever will. But then it came time to log into the server and do something, and he didn't even know how to open a terminal and SSH into the box! So, no, I don't believe a simple coding test will find people who are "10x" in software development. There's a lot more to it than just writing lines of code.
> he didn't even know how to open a terminal and SSH into the box!
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.
When you see someone who doesn't know how to open a terminal, and log into a server at the command, you can assume they also don't know much about 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. You're right; it's trivial to teach that one thing, but that particular one thing implies a learning gap about a lot of other things.
> When you see someone who doesn't know how to open a terminal, and log into a server at the command
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.
> it's easy to teach in one brown-bag lunch session
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.
Yes, but: a programmer who has made it to age 25 without learning how to ssh into a server where their code will end up running is to me demonstrating that they are remarkably incurious about the larger ecosystem within which they’re working. One sign of a better developer is that their horizons are broader.
Or they’ve only worked at BigCo with defined production pipelines and connecting to individual EC2 instances isn’t possible without jumping through incredible month-long hoops, and not available for production at all.
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.
God damn dude. Maybe you piss them off because you call their contributions “interference”. Honestly this is one of the most dickish things I could imagine saying about a colleague’s work.
Wow. That was pretty nasty. I thought we didn't make comments like that, here. I can see that we probably won't be working together, so I don't see why you felt the need to make that comment. In fact, I'm a pretty easy person to get along with, but you'll never know, now, will you? You've already decided how our relationship will go.
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?
So you can't handle someone suggesting that what you said is (honestly and objectively) dickish and maybe the real source of your problem, but you can outright call others' hard work "interference" and it's all gravy and not at all unprofessional or rude?
You've got a skewed idea of "nasty". Have a good rest of your day.
But I didn't call someone else's "hard work" "interference." That was your interpretation. I have just had the very common experience of having my work destroyed by people that really had no qualifications, but did have the right, to mess it up.
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.
At the beginning of my career I worked in a team of 6 developers. Everyone except me was at least a competent developer. One of us did literally 80% of work. Company was paid by head so it didn't care about productivity of others and our client (HP) was happy.
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.
> My advice to 10x-ers is: don't work for corporations. If you can be very productive you are selling yourself short.
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.
> 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.
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.
Agreed on this. If you are a true 10x’er or 100x’er you can do best by making your own company. A year and a half ago I actually did this and recently exited for a good sum. Made a lot more money than if I had kept my salaried position.
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.
I know few like that, had spell myself in my youth. Sadly, you learn in later life, you don't get compensated any more and worse, you set yourself up for burnout. Something I'm aware many did and, dare say, still do. Companies don't care, they'll take your blood but not good at giving it back or, indeed, slowing you down to the rate they pay you. Let alone, compensate for the efficiency (though that may have changed in the last decade or so in some places).
My question is ; if you somehow could level up all the other people on the team to the super productive person's level - how much more productive would the team have been? Clearly it would have been somewhat more productive but I think a lot of this "10x developer" stuff is kind of reductionist - the quality of the overall team being solely the total quality of each individual member.
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 think ego/personality clash are not related to performance.
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..
It probably depends on the company and project. If it's a hugely ambitious one with tons of challenging tasks to work on, then everyone being '10x times better' would mean it'd speed along and get done in about a quarter of the time.
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.
I agree, I've found like 1 or 2 "10x" developers in my career. Before I met them I doubted they existed.
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.
I find it interesting that this was early career. It lines up with my experience, too.
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.
Good point. My ignorance back then certainly could have played a part in my perception, but I don't think I am wrong :) I could go into details why, but I doubt specifics would be interesting to anyone.
I do agree that personal ignorance can make competency look more amazing.
Added to which, corporate bureaucracy often nullfies your impact anyway.
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.
"I think 10x developers, like world-class athletes, musicians, and authors, absolutely do exist. You’re just not going to find them with a coding test." well there you go. exactly.
100% this. I've interviewed a great many candidates over the years, and the coding exercise has always been an incredibly valuable litmus test. It gives the interviewer a chance to see whether or not the potential employee has the knowledge of the language and skills needed to do the job. If a developer can't even figure out how to do a basic function on demand, how are they going to be able to contribute to the team? If a developer won't do a basic function on demand, then that's an instant disqualification. Anyone can say anything on a resume, and there needs to be a way to validate that it's not just a fabrication.
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.
Tests are there to make sure the focus is on people who like puzzles and not those who proceed slowly in order to keep key product features in mind while also composing plenty of tests and documentation and working with the team to be sure of direction and consensus.
> and not those who proceed slowly in order to keep key product features in mind while also composing plenty of tests and documentation and working with the team to be sure of direction and consensus
That's not exactly true. I use coding tests to observe whether the candidate understands what they are doing and have organised approach to the problem or they just throw stuff at the wall, recompile the code and see if it works.
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.
What you've described sounds roughly like what wiseowise said, though. I think 10x/0.1x is a bit of an oversimplification - there's no ISO Standard 1x Developer you can compare to - but if someone says they're using tests to filter out "0.1x developers" that could be definitely be interpreted as them weeding out people who can talk but not actually program.
I use coding tests to weed out potential employers. As a general rule I'm barely willing to even interview. I can't remember the last time I spent more than 30 minutes "interviewing."
That's fine. Some people don't want to put any effort getting a job or are not willing to show if they know how to program.
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.
I literally LOLed. You describe an interview process which attempts to compensate for your inability to quickly assess a person's talent/fit and try to play it off as if you're doing a favor for talented people you are interviewing. Then you had the gaul to be smug about it by implying I wasn't in the "smarter" category. I'm so happy to be at a place in my career where I don't have to tolerate being spoken to like that anymore.
> You describe an interview process which attempts to compensate for your inability to quickly assess a person's talent/fit
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".
In my 20+ year career I've been on the interviewer side more than the interviewee side. I've hired dozens of people, never took more than 30 mins to make a decision, and never recommended a false positive. Hiring/interviewing/managing is not my primary role, it's something I do occasionally as a side-task. It's possible and I do it myself.
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.
You can count me amongst that "we". I certainly don't like interviews that torture the candidate, and to be honest I think the bigger tech companies primarily use them as an to filter X-hundred candidates down to a more manageable number. But I do think find that assessing someone's ability can take a little more than a casual glance at their CV and a brief chat. If your interviewing strategy works for you - and it seems that it does - then more power to you.
I think folks miss the point when thinking about 10x devs. The point is that there are some folks out there that can do the work of entire teams or entire companies.
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
I am sorry but I just get annoyed reading opinions on what 10x means.
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.)*
That's what's described in The Mythical Man Month at some lengths. No matter what the process, there's communication overhead that increases somewhat exponentially with team size, which means you get diminishing returns from adding more devs at some point. A solo developer is in my experience always insanely productive compared to a team, as long as it's not a junior at least. But there's still a team size at which the larger team breaks even and can be more productive - plus you have a better bus factor.
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.
Agree a lot with this. The test (quoted below) has absolutely nothing to do with the skills that a 10x developer possess.
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 think my coworkers mostly think of me as a 10x programmer, and I think this is due to a few factors:
- 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.
Code is commodity. It's brick laying. It's the modern blue collar job. The "10x" myth can be hotly debated precisely because there's only so fast you can lay bricks, and thus extreme productivity variance seems implausible at that level.
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.
Oh! So we have to see if we are referring to a nominal or ordinal measurement: a nominal one like Mohs, where hardness is relative, or ordinal where it is scaled.
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).
I know 10x programmers exist cause I am one. I guess you'll have to take my word for it.
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.
10x engineers unfortunately seem to never make it up the management chain, as they are threats to management and management just wants them to output things. Ironically 10x engineers can do architecting, project planning, and run sprints without managers and do it better, but will never be even offered a low level management position. Bonuses might be good but long term career prospects for any company seem pretty low if there's intent to "move up", unless maybe for a startup or making their own business.
Is this really true? I joined a small team in 2017 and carried them to success by building many applications at high speed. Now my team has tripled in size since then, and I have had multiple promotions and have around 5 reports on average
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)
This is rational though. Why would you take someone who's a 10x at their current job and move them to a different job with a completely different set of skill requirements where they might not even be a 1x, and almost certainly won't be a 10x. It's a negative for the developer if they wanted to move into management, but I don't think it has anything to do with management feeling threatened.
I have tried moving up the management chain (PM/TPM/Architect/C*). The biggest challenge I found is that generally I was still the most productive engineer available to apply to most problems, so I still spent time writing code (the alternative was like watching a fire burn out of control while holding a fire extinguisher). In some orgs (particularly bigger enterprises) that hit up against a wall of expectations for what people in my role could/should do. Eventually I settled on consulting as better fit--I still do stuff across the full spectrum, but as an outsider I'm not expected to fit into a particular box.
So, I am interested in your specific examples, and they may counter what I am about to say.
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.
Ok one specific example. I'd say the 10x part isn't about productivity but insight into the problem. Most people solve the problem as given, but the times when I've been 10x I managed to change the definition of the problem to something simpler, and easier to solve.
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.
so my bag at the moment is software is a form of literacy. And that implies that (for now) some people can read and write and some cannot.
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.
I am fascinated by the psychology of this as much as anything.
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 !
> if you had walked in a year previously with exactly the same plan would you have gotten any traction?
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.
Oh it payed good! But it cost me plenty in burnouts too.
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.
10 times programmers don't exist. Maybe a 2 or a 3 time engineer at most. That doesn't take away from your valuable contributions to the projects you have worked on. However, as you describe, you get brought in to solve a specific problem. You don't have to worry about compliance training, town halls, sucking up to managers and the other endless time sinks you have as a permanent employee.
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.
10x programmers, and dare I say, 100x programmers exist. I believe one works in my team. It's not the speed at which they write code, but the intuition and motivation with which they write it.
The code is as solid as houses, yet as flexible as a piece of plasticine.
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.
There is enough feeling insulted going around without having to do it by proxy. And then you go on to directly insult me, irony. Don't worry though, I'm not insulted. My quip was based on the GP's overly flowery language used to describe 10x programmers, that is all. Lighten up Francis...
Could be. That same user says they used to use MacOS and hated how the UI got in the way, and now they use Linux, and like it, but that the Mac UI is 'more beautiful'. Those are all common opinions one might have, but it's unusual to see someone driven to Linux by Mac UI getting in the way, saying it's 'beautiful' when it's the thing that drove them away.
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.
The problem with 10x programmers, and I say this as a 10x programmer, is that once you realize that you're 10x as efficient and effective as your colleagues it can lead to cynicism. You quickly realize that everyone around you is also making big bucks working at FANG while they work on their handful of items each sprint. Rather than destroy yourself, you can outperform everyone by operating at 2x efficiency. Perhaps this is a combination of cynicism and age.
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.
I somewhat agree with the demotivation aspect, but you don’t need to change your process. 10x is a descriptor of productivity not time spent. You can still do what made you a 10x (e.g. read docs from scratch to get an understanding of everything). Even if you only spend 4 hours a day on it instead of 8, odds are you’ll still end of ahead of the 1x sooner or later even if you don’t have results immediately.
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.
If you've been in the industry long enough to experience working on a variety of different projects and teams it's an easy sell to understand the concept of a 10x programmer, but the 10x programmer also isn't as exciting or "sexy" as we make them to be.
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.
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.
I'm a 10x developer for a few weeks a year and a 0.1x developer for the rest. It averages out to about 2/3 of a developer which ends up being good enough for my job.
I'm currently a 0x dev at rest, recovering from burnout. But when conditions are right (given autonomy and not micro-managed), I've been able to achieve even 1000x by writing tools that empower many devs and users all at once. I think most companies and managers don't know how to manage anomalies like this, and will underpay and overwork them until they're completely ineffective and unproductive.
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.
I've been anywhere from a 0.1x to a 10x programmer. Possibly even 0.01x to 100x we you count the years-long impact that architecture decisions can have.
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.
The main takeaway for me is that a 10x person is thinking at a higher level - about real objectives, but is flexible about how to achieve them.
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.
Schopenhauer touches on this in his distinction between genius and talent: talent is the ability to hit a target others cannot hit; genius is the ability to hit a target others cannot see. Whether or not we want to elevate them to the category of genius, there are clearly programmers in many organizations who fall into the latter category relative to their peers in the organization.
It feels like we always defined 10x programmers as those that "make" things 10x as fast.
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 call those -1x developers. Knew 2 of them, in both cases entirety of the code they done ended up being replaced for bug/bad design reasons.
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 think 10x developers, like world-class athletes, musicians, and authors, absolutely do exist. You’re just not going to find them with a coding test.
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".
Of course 10X programmers exist. Nobody debates the existence of 10X athletes, writers, painters, etc.
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.”
I like the sports analogy to explain a 10x programmer.
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.
There seems to be a convergence of largely orthogonal skill sets here, which may create confusion about what the most useful components of a 10x are.
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.
We can keep discussing this forever and get nowhere if nobody defines what is meant with 10x. Ten times what compared to what under what circumstances?
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?
> I think 10x developers, like world-class athletes, musicians, and authors, absolutely do exist.
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 ;)
10x programmers exist because the average programmer has very little productivity. A high-performing marathon runner can complete a marathon in about 2.5 hours -- if the average person ran a marathon in 25 hours, then that would be a 10x marathon time. This is the situation we find ourselves in with software, the bar is very very low.
But the same way no one ever runs a marathon in 20 hours, the average developer isn't 10 times slower than the most efficient ones either.
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.
It blows my mind that this is so contentious and the only reason why seems to be that programmers think their job is unique or something.
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.
Would it be anywhere near as contentious if folks weren't either constantly misinterpreting the scale of the original study involved or else going No True Scotsman to death on the definition? Would anyone care as much if the job interview process in our industry wasn't also infamously infuriating? Or if enough of us weren't familiar with egotistic assholes whose productivity wasn't necessarily the result of any particular innate skill? There are a lot of confounding factors for any given anecdote.
Whether there's any fundamental truth doesn't much matter, everyone wants to bend the idea to fit their own agenda.
I don’t understand what people mean by 10x programmer.
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.
> I don’t understand what people mean by 10x programmer.
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.
The specific number ten is tricky because in a healthy environment, the effect tends to dilute. The difference often appears when a team penetrates into the jungle of a new technology. Some people are much better trail blazers than others and in that situation 10x or even higher multipliers are not unusual.
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.
I think the term was, if not invented, then at least popularised by Joel Spolsky in one of his blog posts. Initially the term was purely positive and did not imply any negative traits.
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.
I believe the term comes from a study done my Tom Demarco, and was about developer performance across companies, on an equal task, with a somewhat controlled level of experience.
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"
Indeed the experiment conducted by the CMU SEI seemed as if it were designed with the specific intent to disprove the 10X factor that multiple other studies had shown. They first taught all the developers to follow the CMU SEI "Personal Software Process". I am thankful for the CMU SEI PSP, because it's so bad that we've been able to hire great developers who fled from companies that instituted it. The process forces developers to record all their time "on the major activities needed to complete a solution that passed all required tests, including planning, design, coding, testing, and personal reviews" during development. Clearly handicapping developers with ineffective bureaucratic processes up front will add a large constant to everyone's time, which then decreases the ratio of their times.
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.
It has always been obvious to me that 10x programmers exist and I've been bemused by the backlash against the idea of the 10x programmer.
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.
My experience is that you can find developers who are 10x as productive as their peers, but rarely at the same company. That is, the average engineer at company A is 10x as productive as the average at company B.
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've seen it at the same company. Different people have a vastly different likelihood of coming up with workable or even good solutions and execute them in a timely fashion.
When I was young, I worked in a factory. Each worker had to make 2000 parts per shift [numbers approximate]. I did 3000 every day for a month. At the end of the month, I received a bonus from the management, but the quota for everyone was increased to 2500. I barely escaped from the crowd of angry workers. Since then, I tried not to be the 10x programmer.
The premise of this blog was this: the author budgeted 6-8 weeks to tackle a problem that he finished in 3 days. That doesn't make him 10x as productive as someone else. It just means he is really bad at estimating how long it will take to solve a problem.
Estimating how long it will take to figure something out is a devilishly tricky problem.
For simple work, sometimes you can only optimize a little, let alone - 10x.
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?
10x programmers exist but are so rare you can’t hope to staff your team with them. More common is the self-described 10x programmer who doesn’t communicate, doesn’t document and leaves a mountain of unmaintainable code in their wake, then move on to the next project leaving you holding the bag.
In my experience, people do not use "10x" as an actual output metric, but rather as a rough _replacement value_. You could give me 10 other engineers for a quarter or just that one, and I'll be on track for the release either way.
From my perspective, the entire problem is just semantics.
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.
Price's square root law states that half of the literature on a subject will be contributed by the square root of the total number of authors publishing in that area.
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.
Building software is like building a house - a 10x general labourer, who can lift 10x the weight and do things without a break is great, but it really won't get the house built much quicker.
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.
If you are measuring productivity, the authors of significantly popular programming languages are 10x via their programs enabling the users of the programming languages to develop software and the economic value that software provides.
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.
One guy I worked with whom I would describe as a 10x programmer was not only unbelievably productive as a software engineer, but he had a fantastic attitude. He was the antithesis of arrogance and was universally beloved. He was both a leader and a genius, but the first word anyone would use to describe him was "humble" (and not in a self-conscious or ostentatious way). He was enthusiastic, open to new ideas, intensely curious, and was also notable for how much he wanted to see other people succeed. I've never met anyone else like him.
"10x" is just the wrong paradigm to explain the phenomenon. The person is not working at a throughput ten times higher than another person. It's more of an exponent that compounds over time. The best tech people can save a rapidly growing firm dozens of hires (or more) over time through better architecture, documentation, processes, communication strategy, etc. There's no way to suss this out entirely from an interview, but a smart interviewer can certainly get an idea if they ask the right questions.
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.
I can't wait until we get "The myth of the myth of the myth of the 10x programmer", "10x programmer myths all programmers believe", "10x programmer myth considered harmful", etc.
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 would say that the best programmers don't change the multiplier, but the exponent, so that the factor by which they're better than the average increases with the size of the problem. This is why you might not see as much of a big difference with a test lasting a few hours, as you would with one lasting weeks, months or years.
10x is only an positive if she / he makes others more effective as well. If they detract - and we've all seen'em - then the metric is the delta between the 10x and the affects on the rest of the team.
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 and 100x are not myths. They exist. Once you work with them you will know right away. You will walk away in awe and in shame of knowing that you will never ever be that good.
There are multiple types of 10x programmer of which I was each at some point in time and shall be when things align. 1st type is "expert" with accumulated memorized domain and code base knowledge as well as organically used tools enabling to scale productivity. 2nd is autocode/reduce-ambiguity which is sweet. 3rd is smart out of the box quiet lazy type to point the right angle at the right time/space to save and this type is the sweetest :-)
Do we really need to rehash this every couple of months? I mostly tend to enjoy the back and forth on it but even I am finding it something of a pantomime now :-(
An idea I had was professional appraisal website Where one developer can evaluate the skills of another developer and how effective they would be working with them.
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 wonder if the study this cites is powerful enough to find a 10x developer. Generally you find the biggest jumps in ability on the far right of the distribution graph, so I would expect a genuine 10x programmer to be much rarer than the 99th percentile, which seems about the limit the study is able to reasonably talk about with ~400 participants.
I'd be betting more like 99.9th or even 99.99th percentile would be more like it.
If only it were that simple. You can't automate IQ, experience and vision. 10x developers are regarded as such because of the quality of their output, not just sheer volume.
Had a project where the tedium work was cranked to 11. I automated that because I sure was not going to do that for every time I wanted to deploy some code. I also automated the semi complex task that you only do every 2-3 years. Because I sure was not going to remember the steps and I am 100% sure it would just get lost in our sea of documentation. Spinning a new env is mostly just running some scripts instead of days of filling in fields. Computers do the same over and over exactly the way you told them to. Use them. On the other side of that it is dead easy to over complicate something. I am dealing with a project like that now. 5 layers of indirection, model view, the testing framework is solid, the whole thing. It is a single form app with 3 buttons and 4 edit controls.
If I remember the quote has to do with programmers who are worth 10X more, which most programmers tend to think of as being 10X better programmers. Not sure what would make them 'worth' more in Jobs' view, but it might not be just their ability to program. That said he worked with Steve Wozniak - I guess that guy might count as a 10X programmer for just about anyone.
The only way somebody is 10x the average person is when the average person lacks the skills to participate in the domain in question. Unless you really mean 10x the typical competent field-members, and such people are staggeringly few in number. Like a literal handful. And such people are going to be really bored unless you’re out solving unsolvable problems.
I have met a few in my life. They are exceedingly rare and I have seen them burn out because of their intensity. Some problems require a particularly acute mind, others you can actually "throw programmers at" and get results, it depends on the problem at hand (quantity of work vs. innovation of work).
> I don’t know anyone 10x faster than their peers in solving well-defined programming problems
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.
The best folks to work with are the 10x programmers who just make things flow for the folks around them. I've absolutely worked with folks who by being the oil that made their teams flow turned everyone around them into a 2 or 3x programmer.
If you're ever on a team like that, it's just a joy.
Everyone wants to imagine themselves as a 10x engineer, but by definition most of us are 1x engineers. Hell, a lot of us are 0.6x engineers, and that's just fine. Nobody can will themselves into being superhuman, and even superman can't keep it up forever without a break.
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.
I’m not sure I see a difference between this 10x engineer and somebody who had a good idea. Having a good idea isn’t a skill.
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 myth (not necessarily this article) feels like the "no true Scotsman" fallacy, or motte and bailey. Basically, given certain constraints, like well-defined problems, of course they exist. Given others, of course they don't.
Was this blog compromised in some way? "Idea" in the second paragraph links to to an obvious content farm/spam site for no particular reason. Strangely enough, there doesn't appear to more instances of this from a cursory glance.
There are instances in other articles, including the latest one from December. It's a WordPress site and the links are baked into the HTML so yes, it's likely running a compromised plugin.
The myth of the myth of the myth of the 10x programmers.
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.
Tests tend to exist so that you can be rejected. Let's not kid ourselves - most of the time people hire based on feelings; and not only about you but also about how they feel at that specific moment.
This is not a question of someone being 10x what you are.
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.
I don't think this is really in good faith, what is meant by 10x programmers is exactly that they are 10x more productive in grinding jira tickets, not that some people know more and are wokring on harder problems, etc.
10x programmers aren't going to be good at grinding tickets.
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.
Anyone would work faster and better alone, it just doesn't really scale. Building something yourself is much easier than working in a team, the bigger the teams the harder it is.
i agree, except for the scaling, a 10x can make an entire project it takes 100s of engineers for, and they'll do it in magnitudes less code.
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
well, if it's a short term use and throw kind of project/tool then sure I can go with 1 "10X programmer", but if I were a stakeholder in a long term project I wouldn't put all my eggs in a one person team.
Reminds me of a software team having one surgeon and the others are support staff--in no way denigrating, but equally essential with their skillsets, to execute on the (skunkworks?) project.
I think it’s means “there are coders out there who are consistently 10x more impactful than the average coder,” and this could be the result of simply speed or through other methods — finding better solutions etc.
Exactly this. I’ve seen architectural decisions that over time lead to exponential work to implement new features. An architectural fix can lead to a big-O difference in productivity, not just 10x (a constant factor).
10x compared to the worst programmer definitely exists. but there is no average programmer. that's like saying "average sports player". pocket billiards and Olympic lifting are both sports.
Innate ability might be normally distributed but as people interact with the environment over time and realize gains in skill, ability becomes more like a power law.
“Equity” in a private company is statistically meaningless. You might as well have said you gave them Monopoly money. I can’t pay my bills with “equity”, investors get first preference, dilution etc.
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 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.”
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".
“A bonus position” could have meant “a bonus title”, higher up equity position, etc.
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).
10x = It takes 10 people to clear the mess they left behind. In my 15 years of career, all people I have seen who were referred as 10x were the people who took terrible shortcuts to deliver whatevs they try to deliver and when it comes to building on top of that thing everyone who touched that hot mess had a miserable life.
At first I thought no it must be lognormal since productivity must be at least marginally more than zero, but then I realized that's definitely not true: I know developers who definitely have negative net productivity on the team.
as a 1-2 (depending on proj). I try to bring them up and try to help them. But some people either do not gel into the group or they are hopeless. But I hold out the eternal flame I can help them be better!
Yeah. And I think 10x coders are probably as rare as professional sportsmen or members of a concert orchestra. They exist, but does your business need them?
Of course it would be nice if coders that rare were paid like pro-athletes...
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".)
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.