> The best explanation of the concept and its basis the article “Productivity Variations Among Developers and Teams: The Origin of 10x” by Steve McConnell. Here are the key things to know about “10x engineers”:
> 10x refers to the difference between the best and worst developers, not the best and average.
The cited article is using a different definition of 10x engineer than I'm aware of. There's hardly a limit to the worst and I'd believe 100x or 1000x variation with this interpretation. In fact the worst are negative so don't even work on this scale.
If you had kept going down the list, you'd see this:
> The studies only compare differences among developers who actually complete the task.
> Their figures don’t take into account the people (~10% in some studies) who didn’t even finish. Nor can they take into account the real-world cost of software that is nominally completed but is so buggy, flaky, or hard to maintain that it has to be rewritten by someone else."
I think one factor for 10x productivity is to be in an environment that allows the flexibility to do things in a different way. Most companies prefer tight control so you can’t really perform at your best.
It's a nice write up, but the methodology is based on productivity as measured against coding, debugging, and execution speeds - which does really capture how much more impact a good engineer can bring.
The reason is that the impact can't me measured because we can't foresee the inventiveness of a brilliant engineer - if we could foresee then we are that brilliant engineer and are inventing ourselves. For the same reason the act of predicting scientific research is impossible because that would be the very product of research.
There's no upper bound on what a brilliant engineers can do, I've known people that you could not replace with 1000 mediocre engineers working for 10 years and they would't produce the same innovation, creativity and automation.
I came here to say this. Because programming is a very high leverage activity, what matters much more than coding speed is the quality of judgement. And that can vary much more than 10x. And the funny thing is the market largely ignores this for programmers, but recognizes it for CEOs. Why are there no rockstar developers pulling in ten million a year? They do exist, but exclusively because they founded a company. I think this doesn't exist in programming because programmers aren't given the freedom to exercise that judgement. Instead they're largely treated like replaceable cogs executing on the vision of other people.
I think it's because programmers generally operate within a framework that guides and controls them and that becomes the limiting factor. It's like having a car that goes 10 times as fast as others but you're driving in the city, so all the traffic gets synchronized at the traffic lights.
Those two comments perfectly describe the issue IMO. That also means that activating good developers to be 10x people means they need to be given leverage and freedom to automate, innovate and be creative. And maybe also ownership of the product they create - e.g. shares or simply a special kind of recognition.
I also see the problem with 10x developers - they are by definition irreplaceable which is impossible to manage properly. But for startups which have a small head-count, this may be needed.
I think the leadership component is very relevant here. A project manager / leader needs to be able to a) identify developers who could be 10x developers, b) develop their characters (some developers may be lazy or undisciplined or have anxieties that hold them back, so this needs to be solved first), c) recognize good technical skills and realistic self-evaluation (a developer that always wants a rewrite because he's certain that he will do it better than everyone before him vs. someone who tries to find a more reasonable way that may involve a rewrite).
Overall, this is a very difficult task. If you let developers that have undeveloped characters manage themselves, they'll create a huge mess. And personal development is generally a very difficult task and not something that a leader can control for most parts.
I'd say we do see that. It's the business model of Sand Hill Road - find talented 10x Devs and shower them with VC money. It seems to work often enough that there are many funds all searching for such people.
Why are programmers not treated like CEOs in terms of pay levels?
I believe it’s mainly attributable to the capitalist hierarchy we live in. Those in and around the ownership of companies make the most money. In large part because of the leverage that the labor/employees provide. As the world has opened up with free trade, businesses have scaled and this has increased further with the internet and computers.
Those selling services to business owners i.e. M&A bankers (glorified real estate agents for businesses), M&A bankers and CEOs have all become richer and better compensated as business owners have gotten richer.
It’s all about power, position and where you sit in the hierarchy that dictates how much you get paid and not necessarily the value you bring to the table.
Having said all of this, I’m still a capitalist and I’m trying to play the game...ex-software developer turned investment professional...
I don't think it's his description that got him downvoted. Rather it is his statement in the end where he "sold out" and became complicit in a system that a lot of people hate.
I sold out because as a software engineer I was making GBP 23.5k a year plus over time. I had a great review and was the “star performer” on my project. They were hiring people with my skill set for 28k so I asked multiple times for a pay rise and got turned down.
I lived in the London area and housing is expensive. Around here financial services pay more and I wanted to be able to buy a house. I left for job that paying 57% more for less hours.
The CEO's job is primarily to raise money, keep investors happy, promote the brand, and set strategic goals.
There is almost no overlap between this skillset and the developer skillset.
It's partly about talent - in varying proportions - and partly about hierarchy. You have to be able to talk to other people high up in the hierarchy as an equal, and you need to display the correct social and personal signals to do that effectively.
> Why are programmers not treated like CEOs in terms of pay levels?
Because of scope of impact. The scope of impact of a CEO is the entirety of a company. A bad CEO can destroy a company, a good CEO can make the company financially successful and desirable to work at. A regular engineer, or even a lead/staff engineer is mostly scoped to their own product, and have little ability to impact the future of the greater company.
Why do military generals get credit when it's their soldiers who actually participate in combat and risk their lives? Because the decisions of a general have a much higher scope of impact.
You could argue that being the soldier (or engineer) is harder than being the general (or ceo), but that doesn't change the fact that having the best engineer won't save a struggling company, while a good CEO can.
So, companies (wisely) pay a pretty penny to have a good CEO, because it's worth it.
Yes, precisely. Now if you have a really brilliant engineer who could found a 100 million plus company, but they're working for you by some twist of fate instead - if you treat them like a code monkey they're going to hate it, and you're wasting their potential. This is what e.g. Google does. On the other hand if you empower them and get the fuck out the way, they may well surprise you.
> but they're working for you by some twist of fate instead - if you treat them like a code monkey they're going to hate it, and you're wasting their potential.
Well no one is forced to work anywhere, especially if they don't like it. Fact of the matter is that there is more support for entrepreneurs today than ever before, especially in tech. Electric scooters are getting $100 million funding rounds. There is more than enough support for this brilliant engineer to create his successful company.
"There's no upper bound on what a brilliant engineers can do, I've known people that you could not replace with 1000 mediocre engineers working for 10 years and they would't produce the same innovation, creativity and automation."
You say that, but is your brilliant programmer going to produce the same output at each of Microsoft, Google, or Xerox?
It is a matter of how you use them like anything. If you do your attribuitation wrong you will get nonsense anything.
If you have a 10,000 horsepower engine pumping water into a very hot large sieve vs a 1 horse power one into a sealed container the 1 Horsepower one and then judge the engines by the water gathered at the end.
Some of the people I've encountered over the years who were praised for their speed and "productivity" dragged down the project (and/or the rest of the team) by introducing more bugs (and risk) than anyone else. Upfront perception of "productivity" masks the long-term cost, in so many cases.
IMO the true "10X" developer is the one who boosts the rest of the team through mentorship and leadership -- the polar opposite of the "lone keyboard warrior" frequently portrayed as godlike and outweighing any other team member.
True 10X developers are really good at picking the right tool for the job. They know the OS and standard library of their language very well. They also know patterns for how to apply technology to problems and have read a lot of other people's code. This knowledge translates into up front productivity but also less bugs as things tend to get done right and the correct technology is picked.
I've seen a lot of code bases and it's never the super experienced, incredible developers introducing tech debt and bugs, it's the poor to middling developers.
Getting a given task done fast does not make you a 10x developer.
It's 10x over time, not 10x for a given task.
There's the fast way of doing something, copy and paste some similar code, tweak it with your goals in mind and you're golden.
You also copied every single bug in the code you replicated, and further polluted the base of the software, which is already a steaming heap of unmaintainable garbage because the impetus is for speed over quality, and tacitly encourages developers to do what you just did.
Or you could refactor. You look at what needs to be done and how the current API limits your ability to implement it.
Update the API to integrate the required features, and refactor if the gradual build up of changes has rendered it unwieldy.
Quickly and cleanly implement the new requirements against the improved API.
You just spent a day and a half implementing something that could've been done in two to four hours, ignoring whatever manager was wondering why it was taking you so long - but the next time you need to make a similar change you'll be done with dev in half an hour.
And when that happens the code you write will be clean, simple and unlikely to introduce new bugs.
Indeed. I worked on a team which was "given" a couple of contractors to help us "catch up" to where management thought we should be. They were both useless. Between finding something they could do without damaging stuff, fixing what thay had damaged anyway, trying to maintain the morale of the rest of the team and explaining to management why we would be better off without them... I was easily more than 10x more productive than they were. But the team was in a hellish mess.
I think true -1x devs are also rare like 10x devs. To be -1x everything you "contribute" has to be a net negative. They are out there, but I think they're also rare.
I don't think so at all. It's really, really easy to slow down a team. The most common -1x behavior I've encountered is committing code that breaks something else, poorly executed "refactoring", misunderstanding the requirements of a task, and asking too many questions.
I've worked with -1x developers and have been one myself. I'm sure lots of other people here have committed these infractions at some point or another. But consistent offenders end up working on low-importance silo projects.
We all do that stuff from time to time, but I rarely find someone who is consistently that bad in everything they do. I have seen them, but my point is they are also rare.
This is the danger of the '10x programmer'. The person 'gets shit done' fast and furious, but at the expense of the wider system which happens to be the team around them.
To the outside (managers etc) they look like they're a 10x programmer, but in reality they leave a trail of destruction and a mess that others have to clean up after them.
I have no doubt that 10x programmers do exist, but I'm not sure I've worked directly with one yet.
I think there are different flavors of 10x. The people that I've worked with that I would consider to be of the 10x variety weren't the kind of 'trail of destruction' type that some people tend to talk about.
I worked with a guy, great engineer, great guy, deep domain knowledge and a very solid understanding all the way through the stack. He was a great mentor and only barked when he was absolutely too slammed to help, which was rare. The thing that always amazed me is not only did he consult on all the really difficult stuff and ship it, but frequently you would come back to code you wrote recently and it would look nicer, cleaner and just a little more polished. He'd been in there leaving not a trail of destruction, but a trail of cleaning.
Now, I have also heard of the trail of destruction kind too. They're more like -10x though. They just pump it out really fast, but super low quality. IMO that's a bad kind of 10x to be. It's 10x the recklessness. A truly great engineer is one that can help the team and the company avoid writing as much code as possible. As such I don't consider the 'trail of destruction' 10xers to be 10xers, but rather really fast cowboys.
Agreed. How do you compare a software project that succeeds with another that fails? Isn't the successful project infinite(X)-ly better? Therefore isn't the programmer who doesn't fail actually immeasurably better than the one who does fail?
If most software projects fail (ests: 55% to 90%), isn't the 10x programmer really just someone who consistently avoids failure? If so, a label like '10x' seems to measure concrete skills that don't really matter, yet fails to measure those abstract skills that really do.
you'd need a reasonable definition of "productive" before we can start measuring the spread between the least and most productive engineers. any reasonable definition wouldn't constrain the spread to a single order of magnitude. the real spread is infinite. I think people's intuition is backwards on this as well - if some engineer takes 10x less time to solve some (non-trivial) problem I'd expect some combination of underengineering andor oversimplicification which could potentially set you back by more than 10x your overall "productivity".
> Productivity is not strongly correlated with experience.
This seems contrary to my experience and expectations, although maybe the word "strongly" is what makes it true.
> The inherent traits have a lot to do with intelligence and other thinking patterns that we can’t (or don’t yet know how to) identify and teach.
This also doesn't really match up with my experience. I've had employees start as net negative contributors, and then grow into solid positive contributors over time as they learned and developed their skills.
Either way, the explanatory factors seem like the most interesting thing to talk about: what makes one engineer more productive than another?
But I can say without a doubt that I have met a small handful of people who are many, many times more productive than ordinary developers. Call them 10X if you want, or dismiss the idea that 10X exist, but fact is there are developers who are simply streets and miles ahead of others in terms of productivity.
Why people claim 10X developers don't exist surprises me. Maybe they haven't met any or weren't able to recognise such productivity.
One important thing to take into account when considering extremely productive developers is context:
happy personally productivity +1
unhappy personally productivity -1
deep experience with language/framework/tools/tech productivity +1
average experience with language/framework/tools/tech productivity +0
little experience with language/framework/tools/tech productivity -1
inspired by the mission productivity +1
ho-hum about the mission productivity +0
skeptical about the mission productivity -1
likes the boss/management/fellow team members productivity +1
dislikes the boss/management/fellow team members productivity -1
not impacted by organisational politics productivity +0
impacted by organisational politics productivity -1
provided best tools for development productivity +1
I think this is a great way of looking at it. Coming from the product side of things, I see developers who are vastly more productive than their peers because they have amazing organizational and communication skills. They help keep timelines on track, they keep their peers focused and identify potential issues that a PM without an engineering background might miss. Developers who can suggest small modifications to a product spec that will drastically reduce development time but not greatly impact the overall product are worth their weight in gold.
This perspective saddens me because you’re not describing a productive developer, rather just some employee good at acquiescing to what product managers (often mistakenly) want.
10X developers aren’t wasting time debating scope with product managers. They are too busy doing things that directly help customers and stakeholders, generally as a direct result of flippantly ignoring what product managers say and the ensuing politics over who gets credit and what is politically allowed to be shipped.
One way to spot a 10X developer is that it’s someone getting lots of stuff accomplished despite product managers finding it universally frustrating to ask that person to take on the product manager’s agenda.
Honestly the reason why these people are so rare is not because they are too hard to find. It’s because product orgs can’t tolerate someone whose judgment supersedes their own in regards to what the customer wants. The 10X developer does product management circles around product managers all while getting their own software jobs done in the meantime.
In order for there to be possible options for politically arguing over bonuses & credit for what is shipped, you have to staff most of engineering with passive people who don’t push back on product management, hence very few 10X engineers.
Sad that people downvote without bothering to reply. To me, it sounds like you either don't like your product team in general, or they ignore your ideas for reasons of territoriality, or you're doing a bad job expressing your concerns to them.
Frankly, I don't see why an engineer would know what the customer wants better than a product manager. I do see how an engineer would know the kind of corners they most want to cut, and of course how any human would want to present their self-interest as the group's interest, but I don't know anyone's specific circumstances.
> “Frankly, I don't see why an engineer would know what the customer wants better than a product manager”
The engineer usually spends much more time investigating customer usage data, help center feedback, product features and competitors, all while also having greater familiarity with the engineering implementation (to know what’s feasible / reasonable) and greater quantitative skill to determine the implication of evidence in terms of what actions to take.
One lesson I learned a long time ago is to develop product management as a career growth track for engineers who are interested, because the best way to be an effective product manager is first to be an engineer of that product for a long time and leverage the engineering skill set as the primary skill set for product management.
I've met great engineers who were great at driving product, and great engineers that were terrible at it, or uninterested in it.
I've met engineers who could invent a whole new product out of sackcloth to solve a customer need the business was only dimly aware of, and engineers who used all their knowledge of customer pain points and data to fritter around the edges of their systems, redesigning this or that but making little material progress in addressing serious issues.
I have little time or patience for "engineers > PMs" arguments or vice versa. You should be a team working together to solve important problems, and you should each recognize and celebrate the skills each of you as individuals brings to the table. If you're not doing that, the problem lies with your team or organization, not the profession as a whole.
> “I have little time or patience for "engineers > PMs" arguments or vice versa.”
But some skill sets are more effective at some tasks. You wouldn’t hire a stand-up comic to play quarterback on your football team. There are opportunity costs to doing so that make it a strategic blunder.
It’s really the same, only lesser in degree, when thinking about what sort of background & skill set someone should have when you hire them to manage your product development.
If you narrowly dismiss that consideration by acting like every skill set is equal & every type of person hired into the position of product management can do the job, it’s no less of a strategic blunder.
Part of what I see emerging out of this whole 10x debacle is a critique of what makes a great engineer, and a realization that it means very different things to different people. Moreover, that one person's definition of a great engineer might come with some serious limitations baked in. For example, which keys on their keyboard are likely to wear out prematurely. :-P
The same is no doubt true with product managers. For example, a previous company I worked for divided up PMs into two roles – those who were experts at the business side and decided the larger direction of a product line, and those who were able to turn those directions into unambiguous specs for designers and engineers to produce. Different skillsets, both overlapping with each other and with other positions at the company. Considering those roles separately, you could be a great PM in at least two different ways at that company, but when you start taking leadership, teamwork, and mentorship qualities into account, it's clear that there were even more pathways up the mountain than that.
> This perspective saddens me because you’re not describing a productive developer, rather just some employee good at acquiescing to what product managers (often mistakenly) want.
This is straight up the opposite of what they're describing:
> Developers who can suggest small modifications to a product spec that will drastically reduce development time
Part of the whole 10x package is getting the manager on board and increasing trust, not going behind their back.
It doesn't matter if your manager is rational or not. Establishing trust and being a good coworker also means getting them on board on an emotional level. If this is something that you cannot do yet, then this is definitely a skill worth polishing.
>Part of the whole 10x package is getting the manager on board and increasing trust, not going behind their back.
It's a bit of column A and a bit of column B. Organizational politics often blocks productivity. Often the it's better to ask forgiveness than permission is quite effective so long as you're reasonably astute about how much political capital you have, how much you will make from the move and how much you will spend by the move. Other times it's the ability to build consensus and gain buy in to remove the organizational roadblocks is what can really be a force multiplier.
> “This is straight up the opposite of what they're describing”
but then your supporting quote below that suggests the opposite. The quote about cutting scope (from a product manager’s point of view) is about cutting useful scope, like paying down urgent tech debt, in order to cram in more features or hit a shorter artificial shipping deadline despite no actual impact on any bottom line.
My supporting quote is describing a developer who pushes back against bad requirements to find a better solution, not someone who just acquieses to what product managers want.
I am not a developer, not a product owner and I have no down-voting privileges here, but as an IT manager with over 20 years of experience I think almost everything you wrote is wrong. There is no point in taking sentence by sentence and explain why they are wrong, the answer would take pages. Anyway, the very rare 10x developers I met were not writing 10 times more code in the same unit of time, they were doing things simpler, faster, avoiding unnecessary work and writing very good quality code with sound design and a very small number of bugs. This is how they get to 10x, it is 10x in total productivity and not lines of code.
I think the ability of a programmer to be 10x or 100x or 1000000x depends on the domain. If you are writing a sales tax calculator and need to implement 500 different local state sales tax regulations from a scanned Word document, your best developer is going to be maybe twice as fast as your average one.
But if the problem domain is “write a program to search the Web” or “write a program to allow people to send data-plan messages to each other from even very old feature phones” then the best developers can create millions of times the value of an average programmer.
I was just thinking about how at most jobs I've ever worked the main barrier to productivity is the inability to make minor (in my opinion) changes to organizational policies that have high business logic complexity relative to benefit.
Yeah. Particularly if you don't have the authority to implement changes that would improve things in the long run, there's really no way for a dev to be a "10x" in that situation, even if they may have the ability to be a "10x" dev in other contexts.
Agreed on all counts. Drive and people skills matter a lot. Also, a lot of nefarious people skills are also rewarded.
If senior people like/trust you and you're willing
to stand your ground/fight for something you can
normally achieve significantly more.
Yes, although in a lot of company cultures this is nearly impossible due to the lack of level playing field.
A "software architect" I once worked under liked to play the following game, and he played it awfully well. We'll call him "B."
1. "B." spends days, weeks, or months researching a solution all by his lonesome.
2. "B." presents this idea to the team. It is effectively an edict, but he presents it as a meritocratic chance for others to offer feedback or alternative ideas.
3. The rest of the team is caught flat-footed, because we... just heard about this problem minutes ago, and obviously aren't as prepared as... well, somebody who has prepared. We are also not allocated time away from our scrums in order to research and test alternatives, whereas that was essentially his entire job. In other words, we bore the burden of proof and yet had no time in which to produce said proof.
4. I don't recall one of the edicts-masquerading-as-RFCs from "B." ever being successfully challenged.
Management (who was non-technical) perceived this as evidence of B's superiority, because after all, it's not like folks had better ideas than "B." Since he structured things in a way such that folks really couldn't have better ideas.
Eventually many folks on the team (like me) tuned out and just stopped participating in the whole charade after a few trips around the block. This, of course, was seen by management as more evidence that "B." was the only one with legit ideas.
> If you are writing a sales tax calculator and need to implement 500 different local state sales tax regulations from a scanned Word document, your best developer is going to be maybe twice as fast as your average one.
Assuming "regulations" is actually functionally different and not just some sort of lookup table for a multiplication constant, then having been in a situation with only 10 rules, even such a simple example can easily have a difference on the order of 10x just from prior experience with organizing large amounts of lookups into code (+edge cases, +consistent interface, +etc) instead of into tabular data.
There are constants, marginal rates and limits. Furthermore there are questions about how to determine jurisdictions.
It's very not easy and some companies make bank fulfilling client tax obligations or licensing based on their domain experience.
A scanned Word document -> sales tax calculator sounds more like a death march and my first determination as an engineer would be to confirm if management has done the due diligence as to the buy vs. build cost.
Yea, I’m surprised how rarely domain comes up in these discussions. And, as you say, it’s quite obvious that knowledge and raw intelligence can give you far more than a 10x advantage in some domains.
For an extreme example, imagine that the year is 1993 and the task is to write a program that produces a proof of Fermat’s Last Theorem... My bet is that a certain “developer” named Andrew Wiles would have wastly outperformed a ”team” consisting of every other person on planet earth.
I'm with you on the domain topic; reading the extreme example I'd add repeatability of the performance (on a different problem of the same domain) as an equally important factor to distinguish the developer from the inventor.
oooh oooh oooh, what an interesting example! I recall an interesting comment on NH a while ago where the dev was describing their refactoring of some law code. The original code was if-then-else, and had the same 'shape' as the horrid law it was interpreting. Our intrepid dev redesigned it to use some kind of truth table instead, and was terribly proud. And then the next week the law was amended and a new clause added deep down in one subclause or something. It turned out that the clever algorithmic approach wasn't actually the most maintainable... So, using a sales tax calculator as an example, its possible for two different devs to take to completely different approaches, and for the betterness of one or the other to be in the eye of the beholder until the code has been maintained in production for a long time, by which time doubtless whichever approach was adopted is deemed to be the worse one as the other has no production experience so might be better ;)
I learned a few years ago that there are laws in the UK, parts of which are written in a naturalish language dialect of some complicated proprietary Oracle product. There’s a productivity gain for you (if you’re an Oracle salesperson at least).
Honestly, adding legislature into code is a losing game. Let the developer just deliver a flowchart engine so that even unpaid interns can get to modify the logic.
In my opinion, a whole part of being a productive developer is about empowering people without the technical chops. If someone getting paid 10% of your salary can complete your previous responsibilities, you're technically a 10x developer.
That's a funny example because for me it's the opposite. I'm 100x in the tax domain for my country since I know the tax law by heart and can implement things from the top of my head while my colleagues struggle.
> If you are writing a sales tax calculator and need to implement 500 different local state sales tax regulations from a scanned Word document, your best developer is going to be maybe twice as fast as your average one.
This isn’t software development. It’s mostly translating a scanned document into data. If you leave that task to a non-developer (because it isn’t development-related), I’m convinced you can see a 10x difference in productivity for the remaining work (writing the actual software).
Your post appears to be an argument against the notion of 10x developers and instead an argument for 10x environments where any developer can be exceptionally productive given the right circumstances.
There are environment factors that contribute, not 10x but maybe the 3x mentioned in the article. That makes bad developers work like the average ones and the average as top developers in terms of productivity, to make the parallel with the article. The one thing the environment will not replace is skill: a top developer is also doing the right decisions in terms of design and architecture of the code, an average one will not know how to do that and a bad one will be clueless about the topic.
a top developer is also doing the right decisions in terms of design and architecture of the code
All the top developers I've worked with have been happy to make decisions because they know it's OK to get it wrong. You can change things later. Having the time, resources and authority to make big changes is largely an environmental issue.
I would question the confidence of any developer who claims they make the right call every time. No one does.
I think another aspect to consider is that a good developer who can effectively train and teach other developers on a team gets huge leverage on productivity. It's that leadership and teaching which creates a culture, and amplifies their own efforts through the sharing of knowledge, which then makes it possible to succeed wildly in a project. Looking at just their code might be less than stunning, but once you realize how much of their thought process and technique gets incorporated by others, the impact is huge. And that benefit goes to all of their co-workers' next employers and next projects.
> But I can say without a doubt that I have met a small handful of people who are many, many times more productive than ordinary developers.
I've met a few developers like this. These developers can get tasks done _faster_ than anyone else, guaranteed. But I have never seen one that can do that _and_ produce quality.
Sure, anecdotal, but if you're getting something done considerably faster than others yeah you could just be _better_ than them, but that's unlikely the whole story. You're likely not getting good (if any) tests, good architecture decisions (maintainability), etc.
10x developers may well exist if we're only talking about speed but I have never met one who was a net positive overall (unless we're simply talking about people who are "productive" or "more productive than their peers" but I'd argue that's completely different than what was meant by 10x).
Hell, I have even been called a 10x engineer before by a manager who was trying to get me to work over 80 hours a week. And you know what? It worked. I felt like I was the best, my shit didn't stink, I was getting more tasks done than anyone else, and the entire time I was killing myself to do it. I slowed down a bit for about a month when I had to learn something new and I was fired after working with these same people for 5 years.
"10x engineer" is a marketing gimmick used to gain leverage in various ways, IMO.
It's really interesting to see how both sides approach the problem (without rushing it), but only one of them solves it. That certainly counts as a 10x difference?
> "10x engineer" is a marketing gimmick used to gain leverage in various ways, IMO.
I've been following the discussion, and I think that "10x is a lie" has itself become a dangerous meme. It's already hard to tell some of my clients that developer quality matters, that hiring cheap developers en masse is pointless if they can't reliably fizzbuzz. Now Developer Twitter decides to proudly proclaim that everyone is equally capable as a developer, except some of them are toxic jerks. Sigh.
This has always been the end game of social justice being funded so well. Destroy the professions and commoditize them.
Fortunately for us programming has been and always will be about the transformation of text into other text with a context sensitive grammar. Something that can't be automated and will always fail. Usually with people dying as the catalyst for on-shoring jobs again.
Fair enough. Not everyone will leave their family behind, not everyone will get a visa. But the "rich shores" have a massive statistical advantage in terms of talent because they attract skilled people from abroad, with little migration in the other direction:
Reality disagrees. If software development could be done in India, Ukraine or whatever your preferred third world country is it would be getting done there already.
There's a reason why developers move to one of a handful of cities to be productive.
I don't believe that the majority of comments on Twitter are trying to say that every developer is as as equal as every other. Many of them are arguing that the "10x developer" idea is unrealistic in the sense that management wants to hire someone 10x more productive than everyone else (this story agrees, 10x is a big exaggeration). Some people have worked with so-called 10x developers, who have been slavishly defended from criticism by management, who are churning out piles of code that will be difficult to maintain, it seems that some of those people also have some toxic behaviors.
In terms of the question "do 10x developers exist", I wonder if it really matters. An argument has been made that there are people far better at chess or football or piano than everyone else, so there must be developers who are vastly better than the average in the field. I'm not sure that software development is really the same kind of thing... But even so, we do not have the systems in place that would allow us to recognize such people. All we have, for the most part, are anecdotes from recruiters and managers and many of these stories sound self-serving and exploitative.
It could be the 10x developer exists in the same sense that the 10x CEO exists: every so often one appears and seems to meet the standard. But the closer we look, the more circumstance and the people they surrounded themselves with seemed to be even more important. Often it looks like maybe the particular period of time was a factor as well. And the argument goes on and on, so on and so forth.
That's a more generous reading of the mood on Twitter. I also think that many people have good intentions, and are only trying to reduce the general levels of impostor syndrome.
> Some people have worked with so-called 10x developers, who have been slavishly defended from criticism by management, who are churning out piles of code that will be difficult to maintain, ...
And I have experienced this anti-pattern several times. But I worry that we're throwing out the child with the toxic genius bathwater.
> 10x is a big exaggeration
The actual actual factor is a function of your work environment. If HR hired "nice" people who failed all the trivial interview questions, would that number still seem unbelievably high? That's what some small shops do when developers are hard to find :|
Fair enough, once there's more than a handful of replies a Twitter thread turns into a trash fire. The replies and posts that I have read, insofar as I had patience to read them, struck me this way.
I don't think any organization has the ability to hire exclusively 10x developers, even if they did exist. Large places with deep pockets can afford to hire many people and then promote those they perceive as meeting their own idea of what a 10x developer might be.
On average, I think everyone should try to hire the best people that they can. Companies should try to retain their best people and encourage everyone to improve. Over time, the productive people will emerge and should be valued by the organization. Are they going to be the mythical 10x developers? Maybe, maybe not.
This idea that you can hire a 10x developer to guarantee the success of your project is, in my opinion, a waste of time and money. If you think it's working then I bet technical debt is piling up and it will catch up with the organization eventually.
I don't know about 10x, but the most productive devs I meet are usually the TDD kind, because they don't create as much technical debt, they are faster.
My first team lead was a 10x developer; I still remember searching for the j2ME code that would have taken us two weeks to complete that he wrote overnight -- I remember how dismayed I was to find it all directly in the keyboard event method instead of being spread over to various places it should have been.
So his initial code was a "10x" achievement, accomplished in literally 1/10 (or less) of the time it would have taken the team.
....but the legacy of his "10x achievement" was an increased maintenance burden. So the overall gain was less than 10x. Perhaps it wasn't even a net gain in the long run.
This is a good example of my main beef with the whole "10x" thing. So many superstar developers are lauded for banging things out quickly, while everybody else is stuck cleaning up 10x the mess.
I truly believe that there are 10x developers, but identifying them is nearly impossible unless the person doing the identification is (a) a pretty savvy developer themselves (b) is intimately familiar with the choices made by the "10x" dev and their long-term ramifications.
> But I have never seen one that can do that _and_ produce quality.
I've never seen a mediocre dev produce quality so it isn't needed in order to be 10 times as productive as a mediocre dev.
What I think usually happens is that the 10x dev produces 10x as much technical debt as everyone else, so the team thinks that this guy is blocking all of them when it would have been just as bad if they put 10 mediocre people to do it instead, just that then the blame would have gotten spread out among 10 persons.
Or he produces 10x the quality and 1x the code of everyone else, but his mediocre colleagues doesn't notice that his code is better since everyone else added so much crap so he is seen as just a decent 1x dev.
Timing has a great deal to do with it as well as with anything. Environment and timing can make a 10x coder even better or just average, depends on where the rest of the market is at and if the market timing is right. Though a good developer, 10x level, can probably find something that is timed right to attack, as an aspect of a better than average developer is also finding something the market needs.
When you combine some new technology innovation or advancement, and you are a product focused skilled developer, it can multiply skill even more.
Power or access in the environment/team, along with time, is also key to a 10x or multiple developer output. Almost all really good developers have power to change things or design them from scratch, an 'open' mode where they can research, a shipment focused 'closed' mode and this can make developers more productive.
As an example, John Carmack, probably a 1000x developer. He was also perfectly timed for graphics/rendering/game development to carry the whole industry forward with Doom/Quake and on. The timing was key as he was perfectly positioned with very high skillset and new technology that others weren't in as much yet, he set the standards. As time went on and the new knowledge was taken up by others, with him at Id competing was harder, still a 10x but the timing and environment are much different.
Carmack was also given lots of power and free reign, another aspect of being a 10x+ that is key. If something needed to change to make them more productive, he was the architect and was allowed to make it happen. That access is harder to obtain on established teams without really good prototyping of entire systems that can show how things are better done another way. Lack of power leads to lots of time explaining and selling your ideas over just doing them. The smaller the company the better for the 10x unless the reputation is already established.
Carmack also did some space research with Armadillo and is at Facebook/Oculus now, where he is still amazing but the timing and environment are much different. Competition and funding were harder in the space venture. VR he helped get going while at Id and even helped Palmer Luckey early on, but also the industry is fairly established. There are still leaps to take there and he will probably be part of those with better access.
Shipping is a key to a 10x as well. Carmack shipped.
As with anything successful: timing, environment and access (funding / power) are key elements of allowing good product shippers/creators/developers to flourish and ship.
I think this perspective is totally underrated. When I compare a lot of people's careers I see these dynamics jumping out at me a lot. Timing timing timing. Autonomy too. When you're decent at what you do and you're allowed to do it, it turns out you can do good things. When you do good things you get more of the right kind of experience. Gaining that experience is rare in the first place thus making you even more rare and valuable (in the right context).
I'm glad I'm not the only one out there that sees it like this.
Carmack was also given lots of power and free reign, another
aspect of being a 10x+ that is key. If something needed to
change to make them more productive, he was the architect and
was allowed to make it happen. That access is harder to obtain
on established teams
Yes. This is so key. This is why I (and many others) bristle at the "10x" stuff. It's so context-dependent.
Put John Carmack to work on a legacy maintenance program at some bank where he's not allowed to make any real decisions that affect the workflow or overall codebase, and that guy's no longer a 10x programmer. He's not even going to be a 1x programmer until he learns all of the archaic domain knowledge relevant to his new, miserable job.
Lots of people are stuck in situations like this: 10x (or 1000x) talent stuck in situations where they're performing at 1x or worse.
Likewise, lots of people with 1x talent are perceived as operating at 10x levels relative to their peers in the organization because they've got favorable circumstances: they're allowed to work on greenfield projects while others are stuck doing maintenance, they're allowed to choose tools and stacks that suit their own preferences and skillsets, etc. Or they're the ones that wrote the initial code and are the only ones who really understand it.
I've been in both those situations, and others.
At various points in my career I've operated at 1/10x, 1x, and 10x relative to my peers.
It sure wasn't my work ethic or talent that changed.
Now, some may say that part of being a "10x" developer is striving to put yourself in situations where you can actually be a 10x developer. Well, if folks want to define it that way, then sure. But that sort of presupposes some kind of ideal free market in which people are free to change jobs as often as they like until they have found their own personal little 10x niche. Certainly we all should strive to do that, and many of us do, but there are significant barriers to doing that.
You forgot a multiplier and that is "increases the productivity of their peers and the company."
A 10X developer isn't necessarily more productive in themselves, but they enable increased productivity in everything and everyone they touch.
A strong lead developer who has keen business acumen, steers product strategy to increase value, mentors their peers to up their game and increase their productivity is where you separate the 1X developers from the 10X+ developers. When you end up with a team of these people, this is where magic is made. A developer that brings this value may be many times more than a 10X developer.
There are also people who are simply better at the job no matter the conditions. Bach was a 10x composer, Rembrandt a 10x painter, you could train as hard as you can for your whole life chances are you wouldn't even be close to match their skills.
imho people tell themselves 10x don't exist because it's hard to admit some people are just better. Especially in our industry in which a lot of people confound "work title/achievement" and "identity".
No, you can definitely beat Rembrandt's skills if you spend your whole life doing it as hard as you can. This is why you shouldn't use 10x label, it is wrong and goes against everything we know about the world. It merely tries to put down people, convince people that they simply can be bad at the job, which cannot be farther from the truth. People are just different, have different backgrounds, different experience, different skills. Which means depending on circumstances some people have to learn new skills and start figuring things out from scratch, while some could already be years ahead. This is important, as even the most unmotivated, unhappy, skeptical person in the worst conditions, but a domain expert of a big complex domain will still do a better job, than someone who needs to spend years before even starting doing the job.
Anyway, 10x label is harmful and disrespectful. But I guess this is true for labeling people in general.
> This is why you shouldn't use 10x label, it is wrong and goes against everything we know about the world.
Are there studies that prove that everyone can master any skill if they try really hard? This doesn't match the anecdata I've experienced and seen [1].
> Anyway, 10x label is harmful and disrespectful.
Yes, if we decide that humans are only as worthy as their code. But we can also consider, even in the age of neoliberalism, that economic activity is a tool, not our purpose. Some are more productive than others, so we need to help each other out.
Conversely, if we assume that talent does not exist and everything is just a matter of trying really hard, then the conclusion is that poor (able-bodied) people are simply lazy and deserve their fate.
> People are just different, have different backgrounds, different experience, different skills.
Yes, and if these things make you perform ten times better than your colleagues then you're a 10x. We don't judge people by their hypothetical potential (well actually we do, for a short while), but by their current performances.
It'd say it's more disrespectful/harmful to say that everyone is a Bach, a Rembrandt or an Einstein. It's not just a matter of studying and working, everyone hits a wall a some point, some way earlier than others. Your will to be better isn't enough.
Labels are not harmful as long as they're factual. My light bulb is less bright than the sun, I'm not as good as a painter as Rembrandt, that's the human condition and we have to accept these things. Saying they're harmful and that everyone can become anything they want is a fairytale.
Bach and Rembrandt were artists. Most companies are looking for 10x developers to write systems to manage billing, accounts, inventory, etc. I don't see how we can compare Bach to someone toiling away on a better business software in any reasonable way.
If there are developers out there doing work on the same level as Rembrandt or Bach then they are working in an entirely different domain. Personally, I don't think we have the ability to recognize these people and, if we did, there is no guarantee that their work would be applicable to business systems in the way that the "10x engineer" myth implies.
Isn't it a fact that software engineering is inherently creative? While programming may not strictly count as art by most people's definitions, it is certainly not soulless or mechanical as your comment implies. In particular, Bach's music is so remarkable precisely because it combines mathematical patterns and subjective beauty.
I hate the phrase, but exceptional software engineers "paint with code."
> Isn't it a fact that software engineering is inherently creative?
Yes, absolutely. If you can create a simple, clean, extensible abstraction that hundreds of other engineers use to avoid recreating and testing functionality this could be considered 10x due to the leverage.
I agree that software development is creative, I do think that's an important part of the process. I'm not convinced that every "10x developer" is solving software engineering problems on the same level at which Rembrandt painted or Bach composed.
It seems to me that painters and composers create art that is appreciated much more widely and over a much more varied audience than software engineers. Given that the inner workings of software are visible to a much smaller audience, isn't it likely that their skills are being over-rated?
There certainly exist developers who perform at the same level in their craft as Bach composed. Why wouldn't the positive tail of the distribution exist?
> I don't see how we can compare Bach to someone toiling away on a better business software in any reasonable way.
As long as a domain has virtually infinite solutions, it will inherently imply creativity and quality.
Even on systems with easy logical problems, as long as the architectural complexity is high enough (I guess we start from the tenths of thousands of lines?), surely there will be people who design better, safer and faster (and that will also learn faster).
So they will be definitely recognizable (whether it's "2x", "10x" or "100x"). On the other hand, people with such skills very likely won't work on those systems :-)
Einstein worked at a patent office, where he'd do in a short time what would require other clerks a full day of work. He was the equivalent of a "10x engineer"; he didn't work there for a very long time :-)
Yes, there are many dimensions to "productivity" and this needs to be discussed more.
Twitter has a thing going around lately where people lampoon the notion of "10x engineers". I applaud this, but there's something really fundamental in the belief that there exists someone, "a hero", that can solve all your problems. Many organizations try to find these people, but they don't exist, at least not in the form that they're expecting.
I don't think that folks who would use the term "10x engineer" un-ironically would understand that if you want to cultivate super-productive people this requires that all parts of the organization have to "work right" and not put up obstacles, meaningless KPI's and bullshit goals.
If, occasionally, someone is miraculously able to navigate the dysfunction of an organization and get something great done-- it's not magic, it's not "a hero". Instead of mythologizing them, it would be better to truly understand how they were able to accomplish what they did. My expectation is that behind every true 10x-er accomplishment is a strong team environment, a healthy skepticism of project management and a psychologically safe environment that can tolerate learning, questions, mistakes and trying new things.
Even more important is an acceptance that there are different roles in a work-team and if some people are able to make "slam-dunks" it's typically because others have diligently performed the countless, unglamorous little jobs that made the "slam-dunk" possible. These little roles _also_ need to be recognized. In fact, if you do find someone who has been called "a 10x" they will, invariably, reject that term and instead generously give credit to the people they work with.
I'm not going to specifically address Fabrice, but one thing I have noticed is that people who develop almost purely in one language, within a constrained application space, are able to become extremely productive because their knowledge and experience is very focused.
Consider for example someone who does nothing but C programming on a Linux platform. Say for example they build compilers. And say that's pretty much all they do. That person can become incredibly productive because they know the language and the tools extremely well.
Or maybe someone who writes computer games in Java. The only thing they need to know, and the only thing they have done, for many years is write graphics/games code in Java. That allows them to become extremely productive at writing games in Java. I've wondered about this in regards to Notch (Minecraft developer).
Now consider the modern full stack developer - there's a constant, never ending need to learn new things. New languages, new frameworks, HTML, CSS, JavaScript, ReactJS/VueJS/whatever, SQL, some backend language/Python/PHP/Java/C#, cloud operations EC2/Azure, Linux along with the many related toos like debugging etc etc. This sort of developer rarely comes up to mega expert level because they can't - they need to be very good at learning just enough to get the job done in a wide range of things. Likely they will have expert level in some of these technologies, but the point is that being able to dedicate your entire brainspace to only a few major technologies allows super productivity. The full stack developer is unlikely to be incredibly productive in one particular area.
The other thing that destroys my productivity as a full stack developer is hitting problems/roadblocks in some new thing that you need, but don't know well. This sort of thing can take days of problem solving, where an expert in that particular technology might be able to recognise and fix the issue in seconds. A good full stack developer must be very very good at problem solving because if you can't fix problems then you'll never get to write much application code.
On the other hand, a really good full stack developer should absolutely amaze you with their ability to build every single aspect of a large system including back end, front end, deployment and operations.
It’s a great question but you also need to wonder about the opposite. Was Minecraft successful in spite of Notch’s Java development skills? I know of plenty of products that are successful despite their awful technical prowess. Is the multiplier about making money or technical skill because the discussion around it often mixes both or assumes the former comes from the latter.
people who develop almost purely in one language, within a constrained application space, are able to become extremely productive because their knowledge and experience is very focused.
He mainly uses C and some JavaScript, but a look at all the things he's written suggests that he doesn't really focus on any one area; the first few projects on his page are:
Hm. I would argue that space of knowledge in both compilers and graphics (and maybe even JVM) is pretty huge. And it's a deep kind of knowledge, the hard one.
My point is that there is enough information to be always learning in all fields you've mentioned.
10X engineers deliver tech debt 10X faster than your average engineer.
If there are some out there who truly are of unparalleled execution ability, focus on testing, testability, reusability, modularization, componentization and simultaneously lifting up the team, I've never met one in my years in the industry. I don't think even if you spent 100 hours a week, you could achieve all of these things at once, so you have to compromise somewhere, and I know where people usually compromise. And that's before factoring in work-life balance haha.
In the early days of your company sometimes you do need people to just bang shit out, and eventually, you'll pay 10 1X engineers to clean it up. That period in a company's lifecycle is limited and the 10X'ers are outgrown very fast. Often they don't understand why but to their peers it's painfully obvious.
Having worked with someone I'd consider a 10x engineer who did not create much technical debt, I think the defining characteristic of the group is the ability to choose good abstractions. This of course means that they are better able to shine in different contexts (he was not 10x faster at creating webforms in React, for example).
A story I heard from him recently came from a consultation with a team at unicorn that had spent months modeling a particular problem using a set of graph algorithms. For the past 3 months they'd failed to get the performance they wanted despite a great deal of effort. They brought him in and explained the situation, he realized quickly that the results they needed could be achieved with a simulated annealing style job. Three days after walking in the door he successfully implemented a solution to a problem that had stumped the entire team, in their area of expertise, for 3 months. His career is littered with such anecdotes.
That isn't neccessarily true for technical debt - at least not in a straightforward way. But that applies to all technical debt really. If they say go through various iterations quickly and discard ones which don't work as well and leave quick notes as to how the failed approaches worked or didn't they could generate less debt than an equivalent team of ten. Working fast can lead to underdocumentation certainly.
This is something that came up very often in the discussion on Twitter, too, and I think while there are these kinds of persons, there are also others that are more productive and are able to keep technical dept at a minimum.
I think one can only determine the productivity of an individual by looking at their performance over multiple years on the same piece of software. Otherwise it’s hard to distinguish engineers that are truly productive from others that are only fast at coding.
That's pretty much my observation, I've seen many high-output types, but seen maybe one or two people who "might" be far above average output/quality. Generally I see people who become 10x by pushing down the effectiveness of those around them to 1x. If I write something that works, but am then told to pretty much re-do it all to fit a different design, my productivity becomes pretty low. Yes, I could start with a different design, but my impression has been that there is basically no initial design I can do that won't be re-designed by the '10x' individual, because they feel it's their job to 'improve' everyone else's design.
Now, as another commentor pointed out, some people can be brought in to solve a problem others cannot solve (simulated annealing solution, which I'll just say "oooook" to). Sure, there are individuals who can solve actual problems others can't, but those actual problems are very rare. Most of the problems I have are 'ship the product' types, not 'solve this one very hard problem' types.
In my decades of experience I have yet to meet this mythical 10x or 100x programmer, but what I have seen is every once in a while somebody (probably a programmer but not necessarily) is able to take the reins in implementing a new process, or tool, or framework, or whatever, which dramatically increases productivity for the whole team. Conversely, I've seen programmers who don't try to get on board any such possible initiatives and who drag the team down as a result.
So for me, the question isn't how productive one person is. It's how productive a collective can be as they work together, and how fast is the rate of improvement over time?
Productivity is subjective to what's important for the team or organization. I can be productively wasting time if that's my goal. A 10x programmer with superhuman coding powers doesn't really exist, but a programmer who delivers 10x more value to a team or shared goal can look that way.
> but what I have seen is every once in a while somebody (probably a programmer but not necessarily) is able to [..] which dramatically increases productivity for the whole team.
One of the common alternate explanations of 10x I've seen puts those people into the group: Adding a 1x person to a team results in +1 output for the whole team, while adding a 10x person to a team results in +10 output for the whole team regardless of how much that single person outputs on their own.
The business jargon for this type of 10x-er is "force multiplier". Whether or not they do a lot themselves doesn't matter, they bring the rest of the team up a level to where it's as if multiple people were added to the team.
It may be worth emphasizing that the context of this post is a Twitter thread claiming 10x developers were worth actively recruiting even though they don’t mentor, keep odd hours, don’t communicate, etc. there are certainly exceptional engineers especially in the context of a given company. There are also prima donnas who may be talented but in most cases justify a hard pass.
That twitter thread was a train wreck in so many aspects. It favored individual performance over team work, it suggested a lot of supposed "telltale" signs that were so unrelated to actual work that reminded me of phrenology, and it even included some things that are counterproductive or that you really don't want in a development team.
If anything, that thread described cowboy programmers, not 10x engineers.
That thread certainly tried to box 10x devs into stereotypes. People like Jeff Dean or Steve Wozniak don’t really fit into it (but Linus Torvalds probably does). However, I’d say a many types of work require synthesis from one brain which has obsessively prepared itself over the years. I doubt if any amount of team work by usual musicians or painters could have produce 9th Symphony or The Starry Night.
Those things you describe are more or less fundamentally individual endeavors, however. I'll concede that there may be narrow domains where such work can be a net positive within a larger organization but it's not the way to bet.
The fact of the matter is that the tech industry is based far more on collaboration and collective innovation than individual acts of anti-social genius.
Yes, that’s why I said “many types of work“, not all types of work. I don’t expect any single genius working alone to put man on the moon or build modern cloud service or entire smartphone OS. However, I also don’t expect any committee to invent great programming language or font or new architectural paradigms from scratch.
In the field of scientific research it's obvious that some people are much more productive than the average/worst people. Einstein research output is easily 10x the output of the average physics prof at the top 50 unis in the world.
The question is simply what percentage of people in a given field are 10x, not if they exist.
The question isn't whether they exist, but whether it's just "people" or "people at a given time/place" and in some cases, environment that takes a 1-2x developer and makes them 10x.
The whole discussion is derailed anyhow. Most knee-jerk reactions I've read so far seem to deny the existence of any productivity difference between individuals at all or claim that those 10x engineers must be so efficient because they're anti-social assholes.
Well the 10X developers I have know have mostly been pretty normal nice people.
One of them wasn't even super interested in development outside working hours - he just came to work, seemed to knock it out of the park and go home. I'm not saying he wasn't interested at all - he was mildly interested outside work.
That is probably part of why he is 10x - he works at peak efficency instead of masochistic "long hours mean dedication!" cults which forget the whole damn point is actual productivity.
This makes sense, because long hours can be a consequence of low productivity. The most productive engineers I know work normal weekday hours and spend their time outside of work on other hobbies.
Yeah. I find it an odd response. My assumption is it's normally distributed, so you'll find a sliver of people who just (for one reason or another) blow by the rest. You'll find a lot of average developers. You'll find a tiny minority of people who somehow wound up in industry and you can't for the life you figure out how they made it 15 years.
These days it is very politically incorrect to say that someone is 10X. The LinkedIn is full of profiles with people whose job titles with words like “leader”, “mentor”, “coach”, “team player”. The only thing that is usually missing in their resume is ability to write code or do things that requires actual technical skills. These people eventually show up as your CTOs, architects and they want their people to be team player, mentor, coach, leader - everything other than actual technical work. These types usually hate the concept of 10x devs and deny their existence. I think they have successfully relabeled 10x devs as “brilliant jerks” and “social assholes”. We sometime forget that our industry in not made by these so called LinkedIn mentors, coaches and leaders but likes of Steve Wozniak, Brenden Eich and Ken Thompson.
I would agree but only in the context of tge "smart jerk" meme which bears all of the marks of sociopathic manipulation - especially with vagueness.
Essentially the real jerks are the sociopaths who try to bully everyone else into compliance and not upshowing them with their ability to actually do their job instead of wasting time on office politics. I'll take a whole team of surly coworkers over those assholes any day of the week but I have a strong and justified prejudice against sociopaths because they ruin everything they touch for self-advancement.
For everything that’s wrong with Reddit, I don’t think it’s tall poppy problem is as bad as it is on HN.
Most stories about exceptional achievement on HN will be met with all sort of anecdotal derision. “10x developers don’t exist”, “10x developers are sociopaths”, “10x developers are ‘brilliant jerks’”... other common themes are that people must have exploited others to achieve their success, or that their success is unreasonable because they made too many personal sacrifices to achieve it, or that their success is unfair, because not everybody has the same social skills as them, or whatever other ‘privilege’ people want to nitpick in order to deride them.
This is probably a function of the target audience. If most people on HN work at SV-ish companies where all developers are at a very high level, then the biggest observable difference between them is how obnoxious they are.
This is an eternally frustrating topic. The 10x effect is very real, not mysterious ... and also somehow very overhyped.
The original research in the 1970s didn't claim some programmers were 10x average, just that some were 10x some others. That is directly observable in any shop with more than a half dozen people.
There are "10x typists" too. I type 65 words a minute, sad as a typist but fast for an engineer. Our admin types something crazy like 170 wpm. People who never have a typing class can be 15-20 wpm. 170/17 = 10x. I'm sure a real typist would say 17 wpm people "can't type." From that person's perspective it's true.
I'm typing way faster when I'm typing code than when I'm writing text, because I know most of my IDE's keyboard shortcuts and hence can type 5 lines of code with very limited key strokes.
The reason people doubt it is that developers tend to group at skill levels. It's rare to have a 10x difference in a single shop or on a single team. But it's very common for the top dev at a top company to be 10x the worst dev at another company for any given task.
What most people forget is that the 10x figure only measured those who completed the task. For any given task, there are definitely 0x devs and devs with negative velocity.
I tend to always see it within a single shop at least. Whether it's 10x or more like 3x is debatable but "significantly more productive" is usually obvious.
The same person might be a 1x or 10x developer, depending on the rest of the team. You also need to include politics, experience, processes and many other related bits which can have an impact on how much a potential '10x' dev can actually contribute (indeed - how is the 1-10x measured in the first place).
I had an 18 month period where I was, essentially, a "10x" developer, and a "1x" contributor. My skills didn't radically change in that time period. What changed was the environments and teams I was in. I wouldn't be a '10x' in every team/environment, and I'm not sure that anyone can.
You can also be a 100x programmer, since it's all relative. That's not a very fun way to work though (depending on your personality of course) - you just end up relegated more to mentoring and training than actual development.
That being said, there are definitely people who have a knack for it and can learn fast, and also people who are just not cut out for it, period.
Agreed. I'm a 1x guy, but my knowledge is considerable. Put me in a team where I can share that knowledge and I get valuable. The more bods I can share it with, the greater the value I can bring and it's demonstrably a lot. However I'm not an engine that does the work, more like a lever that others can use to multiply their lifting capacity.
My weakness is I assume everyone around me is as open to (constructive) criticism as I am, and willing to learn from it. This proves often not the case. tl;dr I rub people up the wrong way. This reduces my worth.
> My weakness is I assume everyone around me is as open to (constructive) criticism as I am, and willing to learn from it. This proves often not the case. tl;dr I rub people up the wrong way. This reduces my worth.
Of course another explanation might be that
- your criticism is not constructive
- your knowledge might not always be relevant
- you might not have as much knowledge as you think
- the incorporation of your knowledge might not be what's best for the organisation at that point (e.g. the time investment might not be worth it)
- something else
There's no way to tell for us here, but do not automatically assume that the problem is other's willingness to accept criticism (or your ability to make them accept it). It might be the case, but it might not.
Then I expect to be told "no, you're wrong, here's why..." and then we can discuss, and one or both of us can learn something.
> you might not have as much knowledge as you think
Always true! However if the other can indicate areas of ignorance, I appreciate that and will go away and learn about it.
> the incorporation of your knowledge might not be what's best for the organisation at that point
I see my job as supporting the business. I happen to do that with technical tools, but that doesn't change the fact that I'm there to support the company because it pays my wages.
> something else
Probably I'm just insensitive/thoughtless and should learn to think before speaking. But definitely a fair fraction of programmers get defensive about their code.
FWIW, what I'd meant was I was both a 1x and a 10x at different points. I saw 'developer' and 'contributor' there, and that was a mistake. I'd meant to use the same word in both cases, an emphasize the 1/10 difference. Apologies if that caused any confusion.
If you want to be perceived as an 10x engineer, be the engineer who starts the codebase, write all the code according to your preferences, and maintain a position as arbiter of what the "right way" to do things is in the codebase as the team grows.
I've worked with 2 10x engineers in my career. I don't know if they were precisely 10x, but they were the most productive engineers I've ever seen. At the startup I worked at, this was the VP. When he left, the company almost collapsed because he was singlehanded doing so many different jobs that we didn't know about. I would say that was more of a negative than a positive, but just from the sheer amount of work he did, he was definitely more productive than the entire team.
I had another friend who was also extremely productive. He never graduated from college, but he was a programming genius. One day he decided to learn ANTLR. Then he decided to deconstruct our query language for our product into ANTLR and discovered several bugs and inconsistencies in the implementation that made it impossible for ANTLR to parse it. Then I said "Hmm, it would be really cool to use ANTLR to read our XDR files and spit out some code that would implement the migration between versions." He said "great idea!" and accomplished that over a weekend, hand-constructing the grammar by hand. He saved the team probably 1 month of work every release cycle. He was absolutely astounding and the best programmer I ever had the honor of working with.
This sounds great. Do you think that their ability to deliver 10x value is based on pure programming skills or is it something else?
I'm managing developers and the ones who are most able to develop software aren't necessarily the most productive ones. I would love to know if 10x developers have simply a different mindset or in essence: What is their core skill that enables them to be so much more productive? Being focused, reducing things to the essentials and managing ones will power and time seems to be a subset of that "10x skill".
It's mostly raw passion. You can't get a 9-to-5 worker excited enough to learn something from scratch over a weekend just to do something she thinks is "cool".
There's also a difference between a better programmer vs more productive. I will never be as productive as the two that I mentioned, but I'm pretty good at programming. I have enough experience to know how to develop a feature and a set of code such that it's easy to read, easy to maintain and doesn't have very many bugs. That's just something I've learned over time. Others may be much more productive than me, but I rarely have to revisit features due to bugs. So there are different measures based on what you want from a team.
That's a good point. Honestly, I would prefer a team of developers that are like you vs. outliers that are by definition hard to find and maybe even more difficult to manage. You sound above-average w.r.t your work ethic which is also hard to find and even more important for a strong development team.
> You can't get a 9-to-5 worker excited enough
Would love to know how to achieve that. I use psychological knowledge in my leadership and may have found a way to give people a way to show their full potential. But I'll make further tests before I write about it. Maybe you already have some well-tested tips - I found this infographic and liked it [1].
Now imagine if your organisation scheduled work in such a way that this could have been done by a "1x engineer" during work hours, instead of relying on this chap to bang it out in the weekend.
It would never have been prioritized. The time to convince others that this was more valuable than other tasks would have far outweighed the time that he spent working on it on his own time. He thought it was a cool idea and just did it without seeking permission.
“In one of their studies, Sackman, Erikson, and Grant were measuring performances 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!” – The Mythical Man-Month
Yeah, the study by Sackman, Erikson, and Grant is exactly the study that originated the concept, and it's the first one listed in Steve McConnell's survey, which I link to in the post.
Yeah, but Brooks was the one who first popularised the idea. Mythical Man Month was published in 1975.
And of course he didn't just point to the study, he just used the study to back up what he and many others knew. He also proposed a solution to the problem, the "surgical team", to get out of the idiotic situation of promoting the best programmers to no longer do programming.
277 comments
[ 3.3 ms ] story [ 353 ms ] thread> 10x refers to the difference between the best and worst developers, not the best and average.
The cited article is using a different definition of 10x engineer than I'm aware of. There's hardly a limit to the worst and I'd believe 100x or 1000x variation with this interpretation. In fact the worst are negative so don't even work on this scale.
> The studies only compare differences among developers who actually complete the task.
> Their figures don’t take into account the people (~10% in some studies) who didn’t even finish. Nor can they take into account the real-world cost of software that is nominally completed but is so buggy, flaky, or hard to maintain that it has to be rewritten by someone else."
The reason is that the impact can't me measured because we can't foresee the inventiveness of a brilliant engineer - if we could foresee then we are that brilliant engineer and are inventing ourselves. For the same reason the act of predicting scientific research is impossible because that would be the very product of research.
There's no upper bound on what a brilliant engineers can do, I've known people that you could not replace with 1000 mediocre engineers working for 10 years and they would't produce the same innovation, creativity and automation.
I also see the problem with 10x developers - they are by definition irreplaceable which is impossible to manage properly. But for startups which have a small head-count, this may be needed.
Could it be because a complex system or project tends to be limited by its slowest/least productive necessary component?
Overall, this is a very difficult task. If you let developers that have undeveloped characters manage themselves, they'll create a huge mess. And personal development is generally a very difficult task and not something that a leader can control for most parts.
I believe it’s mainly attributable to the capitalist hierarchy we live in. Those in and around the ownership of companies make the most money. In large part because of the leverage that the labor/employees provide. As the world has opened up with free trade, businesses have scaled and this has increased further with the internet and computers.
Those selling services to business owners i.e. M&A bankers (glorified real estate agents for businesses), M&A bankers and CEOs have all become richer and better compensated as business owners have gotten richer.
It’s all about power, position and where you sit in the hierarchy that dictates how much you get paid and not necessarily the value you bring to the table.
Having said all of this, I’m still a capitalist and I’m trying to play the game...ex-software developer turned investment professional...
I lived in the London area and housing is expensive. Around here financial services pay more and I wanted to be able to buy a house. I left for job that paying 57% more for less hours.
https://news.ycombinator.com/newsguidelines.html
There is almost no overlap between this skillset and the developer skillset.
It's partly about talent - in varying proportions - and partly about hierarchy. You have to be able to talk to other people high up in the hierarchy as an equal, and you need to display the correct social and personal signals to do that effectively.
Because of scope of impact. The scope of impact of a CEO is the entirety of a company. A bad CEO can destroy a company, a good CEO can make the company financially successful and desirable to work at. A regular engineer, or even a lead/staff engineer is mostly scoped to their own product, and have little ability to impact the future of the greater company.
Why do military generals get credit when it's their soldiers who actually participate in combat and risk their lives? Because the decisions of a general have a much higher scope of impact.
You could argue that being the soldier (or engineer) is harder than being the general (or ceo), but that doesn't change the fact that having the best engineer won't save a struggling company, while a good CEO can.
So, companies (wisely) pay a pretty penny to have a good CEO, because it's worth it.
Well no one is forced to work anywhere, especially if they don't like it. Fact of the matter is that there is more support for entrepreneurs today than ever before, especially in tech. Electric scooters are getting $100 million funding rounds. There is more than enough support for this brilliant engineer to create his successful company.
I think there are, but they go by a different name - technical cofounder. There engineers at google and fb clearing one million a year though
You say that, but is your brilliant programmer going to produce the same output at each of Microsoft, Google, or Xerox?
If you have a 10,000 horsepower engine pumping water into a very hot large sieve vs a 1 horse power one into a sealed container the 1 Horsepower one and then judge the engines by the water gathered at the end.
IMO the true "10X" developer is the one who boosts the rest of the team through mentorship and leadership -- the polar opposite of the "lone keyboard warrior" frequently portrayed as godlike and outweighing any other team member.
I've seen a lot of code bases and it's never the super experienced, incredible developers introducing tech debt and bugs, it's the poor to middling developers.
I think there is a bit of Dunning-Kruger going on too. The "architecture astronaut" variety always manage to introduce mountains of tech debt.
It's 10x over time, not 10x for a given task.
There's the fast way of doing something, copy and paste some similar code, tweak it with your goals in mind and you're golden.
You also copied every single bug in the code you replicated, and further polluted the base of the software, which is already a steaming heap of unmaintainable garbage because the impetus is for speed over quality, and tacitly encourages developers to do what you just did.
Or you could refactor. You look at what needs to be done and how the current API limits your ability to implement it.
Update the API to integrate the required features, and refactor if the gradual build up of changes has rendered it unwieldy.
Quickly and cleanly implement the new requirements against the improved API.
You just spent a day and a half implementing something that could've been done in two to four hours, ignoring whatever manager was wondering why it was taking you so long - but the next time you need to make a similar change you'll be done with dev in half an hour.
And when that happens the code you write will be clean, simple and unlikely to introduce new bugs.
Testers are integral to situational awareness in any software or hardware project team.
I've worked with -1x developers and have been one myself. I'm sure lots of other people here have committed these infractions at some point or another. But consistent offenders end up working on low-importance silo projects.
This is the danger of the '10x programmer'. The person 'gets shit done' fast and furious, but at the expense of the wider system which happens to be the team around them.
To the outside (managers etc) they look like they're a 10x programmer, but in reality they leave a trail of destruction and a mess that others have to clean up after them.
I have no doubt that 10x programmers do exist, but I'm not sure I've worked directly with one yet.
I worked with a guy, great engineer, great guy, deep domain knowledge and a very solid understanding all the way through the stack. He was a great mentor and only barked when he was absolutely too slammed to help, which was rare. The thing that always amazed me is not only did he consult on all the really difficult stuff and ship it, but frequently you would come back to code you wrote recently and it would look nicer, cleaner and just a little more polished. He'd been in there leaving not a trail of destruction, but a trail of cleaning.
Now, I have also heard of the trail of destruction kind too. They're more like -10x though. They just pump it out really fast, but super low quality. IMO that's a bad kind of 10x to be. It's 10x the recklessness. A truly great engineer is one that can help the team and the company avoid writing as much code as possible. As such I don't consider the 'trail of destruction' 10xers to be 10xers, but rather really fast cowboys.
If most software projects fail (ests: 55% to 90%), isn't the 10x programmer really just someone who consistently avoids failure? If so, a label like '10x' seems to measure concrete skills that don't really matter, yet fails to measure those abstract skills that really do.
> Productivity is not strongly correlated with experience.
This seems contrary to my experience and expectations, although maybe the word "strongly" is what makes it true.
> The inherent traits have a lot to do with intelligence and other thinking patterns that we can’t (or don’t yet know how to) identify and teach.
This also doesn't really match up with my experience. I've had employees start as net negative contributors, and then grow into solid positive contributors over time as they learned and developed their skills.
Either way, the explanatory factors seem like the most interesting thing to talk about: what makes one engineer more productive than another?
I am a developer, but only a 1X developer.
But I can say without a doubt that I have met a small handful of people who are many, many times more productive than ordinary developers. Call them 10X if you want, or dismiss the idea that 10X exist, but fact is there are developers who are simply streets and miles ahead of others in terms of productivity.
Why people claim 10X developers don't exist surprises me. Maybe they haven't met any or weren't able to recognise such productivity.
One important thing to take into account when considering extremely productive developers is context:
happy personally productivity +1
unhappy personally productivity -1
deep experience with language/framework/tools/tech productivity +1
average experience with language/framework/tools/tech productivity +0
little experience with language/framework/tools/tech productivity -1
inspired by the mission productivity +1
ho-hum about the mission productivity +0
skeptical about the mission productivity -1
likes the boss/management/fellow team members productivity +1
dislikes the boss/management/fellow team members productivity -1
not impacted by organisational politics productivity +0
impacted by organisational politics productivity -1
provided best tools for development productivity +1
inadequate tools for development productivity -1
knows the codebase productivity +1
does not know the codebase productivity -1
etc etc on and on
10X developers aren’t wasting time debating scope with product managers. They are too busy doing things that directly help customers and stakeholders, generally as a direct result of flippantly ignoring what product managers say and the ensuing politics over who gets credit and what is politically allowed to be shipped.
One way to spot a 10X developer is that it’s someone getting lots of stuff accomplished despite product managers finding it universally frustrating to ask that person to take on the product manager’s agenda.
Honestly the reason why these people are so rare is not because they are too hard to find. It’s because product orgs can’t tolerate someone whose judgment supersedes their own in regards to what the customer wants. The 10X developer does product management circles around product managers all while getting their own software jobs done in the meantime.
In order for there to be possible options for politically arguing over bonuses & credit for what is shipped, you have to staff most of engineering with passive people who don’t push back on product management, hence very few 10X engineers.
Frankly, I don't see why an engineer would know what the customer wants better than a product manager. I do see how an engineer would know the kind of corners they most want to cut, and of course how any human would want to present their self-interest as the group's interest, but I don't know anyone's specific circumstances.
The engineer usually spends much more time investigating customer usage data, help center feedback, product features and competitors, all while also having greater familiarity with the engineering implementation (to know what’s feasible / reasonable) and greater quantitative skill to determine the implication of evidence in terms of what actions to take.
One lesson I learned a long time ago is to develop product management as a career growth track for engineers who are interested, because the best way to be an effective product manager is first to be an engineer of that product for a long time and leverage the engineering skill set as the primary skill set for product management.
I've met engineers who could invent a whole new product out of sackcloth to solve a customer need the business was only dimly aware of, and engineers who used all their knowledge of customer pain points and data to fritter around the edges of their systems, redesigning this or that but making little material progress in addressing serious issues.
I have little time or patience for "engineers > PMs" arguments or vice versa. You should be a team working together to solve important problems, and you should each recognize and celebrate the skills each of you as individuals brings to the table. If you're not doing that, the problem lies with your team or organization, not the profession as a whole.
But some skill sets are more effective at some tasks. You wouldn’t hire a stand-up comic to play quarterback on your football team. There are opportunity costs to doing so that make it a strategic blunder.
It’s really the same, only lesser in degree, when thinking about what sort of background & skill set someone should have when you hire them to manage your product development.
If you narrowly dismiss that consideration by acting like every skill set is equal & every type of person hired into the position of product management can do the job, it’s no less of a strategic blunder.
Part of what I see emerging out of this whole 10x debacle is a critique of what makes a great engineer, and a realization that it means very different things to different people. Moreover, that one person's definition of a great engineer might come with some serious limitations baked in. For example, which keys on their keyboard are likely to wear out prematurely. :-P
The same is no doubt true with product managers. For example, a previous company I worked for divided up PMs into two roles – those who were experts at the business side and decided the larger direction of a product line, and those who were able to turn those directions into unambiguous specs for designers and engineers to produce. Different skillsets, both overlapping with each other and with other positions at the company. Considering those roles separately, you could be a great PM in at least two different ways at that company, but when you start taking leadership, teamwork, and mentorship qualities into account, it's clear that there were even more pathways up the mountain than that.
This is straight up the opposite of what they're describing:
> Developers who can suggest small modifications to a product spec that will drastically reduce development time
Part of the whole 10x package is getting the manager on board and increasing trust, not going behind their back.
People are acting like everyone's rational, and all you need to do is just explain things properly. But that's not often the case.
Also, if you have to explain things to someone all the time, it starts getting uncomfortable for everyone.
It's a bit of column A and a bit of column B. Organizational politics often blocks productivity. Often the it's better to ask forgiveness than permission is quite effective so long as you're reasonably astute about how much political capital you have, how much you will make from the move and how much you will spend by the move. Other times it's the ability to build consensus and gain buy in to remove the organizational roadblocks is what can really be a force multiplier.
Both of these dynamics are at play.
> “This is straight up the opposite of what they're describing”
but then your supporting quote below that suggests the opposite. The quote about cutting scope (from a product manager’s point of view) is about cutting useful scope, like paying down urgent tech debt, in order to cram in more features or hit a shorter artificial shipping deadline despite no actual impact on any bottom line.
Being good at your job doesn't mean you're a "10x engineer".
But if the problem domain is “write a program to search the Web” or “write a program to allow people to send data-plan messages to each other from even very old feature phones” then the best developers can create millions of times the value of an average programmer.
If senior people like/trust you and you're willing to stand your ground/fight for something you can normally achieve significantly more.
That and luck on how those above you are trying to play the corporate politics / personal career game.
A "software architect" I once worked under liked to play the following game, and he played it awfully well. We'll call him "B."
1. "B." spends days, weeks, or months researching a solution all by his lonesome.
2. "B." presents this idea to the team. It is effectively an edict, but he presents it as a meritocratic chance for others to offer feedback or alternative ideas.
3. The rest of the team is caught flat-footed, because we... just heard about this problem minutes ago, and obviously aren't as prepared as... well, somebody who has prepared. We are also not allocated time away from our scrums in order to research and test alternatives, whereas that was essentially his entire job. In other words, we bore the burden of proof and yet had no time in which to produce said proof.
4. I don't recall one of the edicts-masquerading-as-RFCs from "B." ever being successfully challenged.
Management (who was non-technical) perceived this as evidence of B's superiority, because after all, it's not like folks had better ideas than "B." Since he structured things in a way such that folks really couldn't have better ideas.
Eventually many folks on the team (like me) tuned out and just stopped participating in the whole charade after a few trips around the block. This, of course, was seen by management as more evidence that "B." was the only one with legit ideas.
Assuming "regulations" is actually functionally different and not just some sort of lookup table for a multiplication constant, then having been in a situation with only 10 rules, even such a simple example can easily have a difference on the order of 10x just from prior experience with organizing large amounts of lookups into code (+edge cases, +consistent interface, +etc) instead of into tabular data.
It's very not easy and some companies make bank fulfilling client tax obligations or licensing based on their domain experience.
A scanned Word document -> sales tax calculator sounds more like a death march and my first determination as an engineer would be to confirm if management has done the due diligence as to the buy vs. build cost.
For an extreme example, imagine that the year is 1993 and the task is to write a program that produces a proof of Fermat’s Last Theorem... My bet is that a certain “developer” named Andrew Wiles would have wastly outperformed a ”team” consisting of every other person on planet earth.
In my opinion, a whole part of being a productive developer is about empowering people without the technical chops. If someone getting paid 10% of your salary can complete your previous responsibilities, you're technically a 10x developer.
This isn’t software development. It’s mostly translating a scanned document into data. If you leave that task to a non-developer (because it isn’t development-related), I’m convinced you can see a 10x difference in productivity for the remaining work (writing the actual software).
Nor about 0.1X environments, companies, and management.
All the top developers I've worked with have been happy to make decisions because they know it's OK to get it wrong. You can change things later. Having the time, resources and authority to make big changes is largely an environmental issue.
I would question the confidence of any developer who claims they make the right call every time. No one does.
I've met a few developers like this. These developers can get tasks done _faster_ than anyone else, guaranteed. But I have never seen one that can do that _and_ produce quality.
Sure, anecdotal, but if you're getting something done considerably faster than others yeah you could just be _better_ than them, but that's unlikely the whole story. You're likely not getting good (if any) tests, good architecture decisions (maintainability), etc.
10x developers may well exist if we're only talking about speed but I have never met one who was a net positive overall (unless we're simply talking about people who are "productive" or "more productive than their peers" but I'd argue that's completely different than what was meant by 10x).
Hell, I have even been called a 10x engineer before by a manager who was trying to get me to work over 80 hours a week. And you know what? It worked. I felt like I was the best, my shit didn't stink, I was getting more tasks done than anyone else, and the entire time I was killing myself to do it. I slowed down a bit for about a month when I had to learn something new and I was fired after working with these same people for 5 years.
"10x engineer" is a marketing gimmick used to gain leverage in various ways, IMO.
That is literally what the grandparent poster said, and matches the first two definitions I can find on Google.
Personally, I often think of this example: https://news.ycombinator.com/item?id=3033446
It's really interesting to see how both sides approach the problem (without rushing it), but only one of them solves it. That certainly counts as a 10x difference?
> "10x engineer" is a marketing gimmick used to gain leverage in various ways, IMO.
I've been following the discussion, and I think that "10x is a lie" has itself become a dangerous meme. It's already hard to tell some of my clients that developer quality matters, that hiring cheap developers en masse is pointless if they can't reliably fizzbuzz. Now Developer Twitter decides to proudly proclaim that everyone is equally capable as a developer, except some of them are toxic jerks. Sigh.
Fortunately for us programming has been and always will be about the transformation of text into other text with a context sensitive grammar. Something that can't be automated and will always fail. Usually with people dying as the catalyst for on-shoring jobs again.
https://www.washingtonexaminer.com/37-percent-of-silicon-val...
There's a reason why developers move to one of a handful of cities to be productive.
In terms of the question "do 10x developers exist", I wonder if it really matters. An argument has been made that there are people far better at chess or football or piano than everyone else, so there must be developers who are vastly better than the average in the field. I'm not sure that software development is really the same kind of thing... But even so, we do not have the systems in place that would allow us to recognize such people. All we have, for the most part, are anecdotes from recruiters and managers and many of these stories sound self-serving and exploitative.
It could be the 10x developer exists in the same sense that the 10x CEO exists: every so often one appears and seems to meet the standard. But the closer we look, the more circumstance and the people they surrounded themselves with seemed to be even more important. Often it looks like maybe the particular period of time was a factor as well. And the argument goes on and on, so on and so forth.
> Some people have worked with so-called 10x developers, who have been slavishly defended from criticism by management, who are churning out piles of code that will be difficult to maintain, ...
And I have experienced this anti-pattern several times. But I worry that we're throwing out the child with the toxic genius bathwater.
> 10x is a big exaggeration
The actual actual factor is a function of your work environment. If HR hired "nice" people who failed all the trivial interview questions, would that number still seem unbelievably high? That's what some small shops do when developers are hard to find :|
I don't think any organization has the ability to hire exclusively 10x developers, even if they did exist. Large places with deep pockets can afford to hire many people and then promote those they perceive as meeting their own idea of what a 10x developer might be.
On average, I think everyone should try to hire the best people that they can. Companies should try to retain their best people and encourage everyone to improve. Over time, the productive people will emerge and should be valued by the organization. Are they going to be the mythical 10x developers? Maybe, maybe not.
This idea that you can hire a 10x developer to guarantee the success of your project is, in my opinion, a waste of time and money. If you think it's working then I bet technical debt is piling up and it will catch up with the organization eventually.
....but the legacy of his "10x achievement" was an increased maintenance burden. So the overall gain was less than 10x. Perhaps it wasn't even a net gain in the long run.
This is a good example of my main beef with the whole "10x" thing. So many superstar developers are lauded for banging things out quickly, while everybody else is stuck cleaning up 10x the mess.
I truly believe that there are 10x developers, but identifying them is nearly impossible unless the person doing the identification is (a) a pretty savvy developer themselves (b) is intimately familiar with the choices made by the "10x" dev and their long-term ramifications.
I've never seen a mediocre dev produce quality so it isn't needed in order to be 10 times as productive as a mediocre dev.
What I think usually happens is that the 10x dev produces 10x as much technical debt as everyone else, so the team thinks that this guy is blocking all of them when it would have been just as bad if they put 10 mediocre people to do it instead, just that then the blame would have gotten spread out among 10 persons.
Or he produces 10x the quality and 1x the code of everyone else, but his mediocre colleagues doesn't notice that his code is better since everyone else added so much crap so he is seen as just a decent 1x dev.
I've had the misfortune of working with a few 1x devs over the years. You would never encounter them on HN.
I'm pretty sure I've encountered -1x devs as well, who contribute little and suck time from the rest of the team.
When you combine some new technology innovation or advancement, and you are a product focused skilled developer, it can multiply skill even more.
Power or access in the environment/team, along with time, is also key to a 10x or multiple developer output. Almost all really good developers have power to change things or design them from scratch, an 'open' mode where they can research, a shipment focused 'closed' mode and this can make developers more productive.
As an example, John Carmack, probably a 1000x developer. He was also perfectly timed for graphics/rendering/game development to carry the whole industry forward with Doom/Quake and on. The timing was key as he was perfectly positioned with very high skillset and new technology that others weren't in as much yet, he set the standards. As time went on and the new knowledge was taken up by others, with him at Id competing was harder, still a 10x but the timing and environment are much different.
Carmack was also given lots of power and free reign, another aspect of being a 10x+ that is key. If something needed to change to make them more productive, he was the architect and was allowed to make it happen. That access is harder to obtain on established teams without really good prototyping of entire systems that can show how things are better done another way. Lack of power leads to lots of time explaining and selling your ideas over just doing them. The smaller the company the better for the 10x unless the reputation is already established.
Carmack also did some space research with Armadillo and is at Facebook/Oculus now, where he is still amazing but the timing and environment are much different. Competition and funding were harder in the space venture. VR he helped get going while at Id and even helped Palmer Luckey early on, but also the industry is fairly established. There are still leaps to take there and he will probably be part of those with better access.
Shipping is a key to a 10x as well. Carmack shipped.
As with anything successful: timing, environment and access (funding / power) are key elements of allowing good product shippers/creators/developers to flourish and ship.
I'm glad I'm not the only one out there that sees it like this.
Put John Carmack to work on a legacy maintenance program at some bank where he's not allowed to make any real decisions that affect the workflow or overall codebase, and that guy's no longer a 10x programmer. He's not even going to be a 1x programmer until he learns all of the archaic domain knowledge relevant to his new, miserable job.
Lots of people are stuck in situations like this: 10x (or 1000x) talent stuck in situations where they're performing at 1x or worse.
Likewise, lots of people with 1x talent are perceived as operating at 10x levels relative to their peers in the organization because they've got favorable circumstances: they're allowed to work on greenfield projects while others are stuck doing maintenance, they're allowed to choose tools and stacks that suit their own preferences and skillsets, etc. Or they're the ones that wrote the initial code and are the only ones who really understand it.
I've been in both those situations, and others.
At various points in my career I've operated at 1/10x, 1x, and 10x relative to my peers.
It sure wasn't my work ethic or talent that changed.
Now, some may say that part of being a "10x" developer is striving to put yourself in situations where you can actually be a 10x developer. Well, if folks want to define it that way, then sure. But that sort of presupposes some kind of ideal free market in which people are free to change jobs as often as they like until they have found their own personal little 10x niche. Certainly we all should strive to do that, and many of us do, but there are significant barriers to doing that.
A 10X developer isn't necessarily more productive in themselves, but they enable increased productivity in everything and everyone they touch.
A strong lead developer who has keen business acumen, steers product strategy to increase value, mentors their peers to up their game and increase their productivity is where you separate the 1X developers from the 10X+ developers. When you end up with a team of these people, this is where magic is made. A developer that brings this value may be many times more than a 10X developer.
imho people tell themselves 10x don't exist because it's hard to admit some people are just better. Especially in our industry in which a lot of people confound "work title/achievement" and "identity".
Anyway, 10x label is harmful and disrespectful. But I guess this is true for labeling people in general.
Are there studies that prove that everyone can master any skill if they try really hard? This doesn't match the anecdata I've experienced and seen [1].
> Anyway, 10x label is harmful and disrespectful.
Yes, if we decide that humans are only as worthy as their code. But we can also consider, even in the age of neoliberalism, that economic activity is a tool, not our purpose. Some are more productive than others, so we need to help each other out.
Conversely, if we assume that talent does not exist and everything is just a matter of trying really hard, then the conclusion is that poor (able-bodied) people are simply lazy and deserve their fate.
[1] https://www.theatlantic.com/health/archive/2017/08/the-dan-p...
Yes, and if these things make you perform ten times better than your colleagues then you're a 10x. We don't judge people by their hypothetical potential (well actually we do, for a short while), but by their current performances.
It'd say it's more disrespectful/harmful to say that everyone is a Bach, a Rembrandt or an Einstein. It's not just a matter of studying and working, everyone hits a wall a some point, some way earlier than others. Your will to be better isn't enough.
Labels are not harmful as long as they're factual. My light bulb is less bright than the sun, I'm not as good as a painter as Rembrandt, that's the human condition and we have to accept these things. Saying they're harmful and that everyone can become anything they want is a fairytale.
If there are developers out there doing work on the same level as Rembrandt or Bach then they are working in an entirely different domain. Personally, I don't think we have the ability to recognize these people and, if we did, there is no guarantee that their work would be applicable to business systems in the way that the "10x engineer" myth implies.
I hate the phrase, but exceptional software engineers "paint with code."
Yes, absolutely. If you can create a simple, clean, extensible abstraction that hundreds of other engineers use to avoid recreating and testing functionality this could be considered 10x due to the leverage.
It seems to me that painters and composers create art that is appreciated much more widely and over a much more varied audience than software engineers. Given that the inner workings of software are visible to a much smaller audience, isn't it likely that their skills are being over-rated?
I think "10x developer" is a very ambiguous definition, and comparisons in other fields are confused because of this.
I'd rather use the adjective "elite". It's more intuitive and unambiguous.
Carmack is without doubt an elite engineer; his work, in my opinion, is on the same level as Bach's in his field.
As long as a domain has virtually infinite solutions, it will inherently imply creativity and quality.
Even on systems with easy logical problems, as long as the architectural complexity is high enough (I guess we start from the tenths of thousands of lines?), surely there will be people who design better, safer and faster (and that will also learn faster).
So they will be definitely recognizable (whether it's "2x", "10x" or "100x"). On the other hand, people with such skills very likely won't work on those systems :-)
Einstein worked at a patent office, where he'd do in a short time what would require other clerks a full day of work. He was the equivalent of a "10x engineer"; he didn't work there for a very long time :-)
Twitter has a thing going around lately where people lampoon the notion of "10x engineers". I applaud this, but there's something really fundamental in the belief that there exists someone, "a hero", that can solve all your problems. Many organizations try to find these people, but they don't exist, at least not in the form that they're expecting.
I don't think that folks who would use the term "10x engineer" un-ironically would understand that if you want to cultivate super-productive people this requires that all parts of the organization have to "work right" and not put up obstacles, meaningless KPI's and bullshit goals.
If, occasionally, someone is miraculously able to navigate the dysfunction of an organization and get something great done-- it's not magic, it's not "a hero". Instead of mythologizing them, it would be better to truly understand how they were able to accomplish what they did. My expectation is that behind every true 10x-er accomplishment is a strong team environment, a healthy skepticism of project management and a psychologically safe environment that can tolerate learning, questions, mistakes and trying new things.
Even more important is an acceptance that there are different roles in a work-team and if some people are able to make "slam-dunks" it's typically because others have diligently performed the countless, unglamorous little jobs that made the "slam-dunk" possible. These little roles _also_ need to be recognized. In fact, if you do find someone who has been called "a 10x" they will, invariably, reject that term and instead generously give credit to the people they work with.
Consider for example someone who does nothing but C programming on a Linux platform. Say for example they build compilers. And say that's pretty much all they do. That person can become incredibly productive because they know the language and the tools extremely well.
Or maybe someone who writes computer games in Java. The only thing they need to know, and the only thing they have done, for many years is write graphics/games code in Java. That allows them to become extremely productive at writing games in Java. I've wondered about this in regards to Notch (Minecraft developer).
Now consider the modern full stack developer - there's a constant, never ending need to learn new things. New languages, new frameworks, HTML, CSS, JavaScript, ReactJS/VueJS/whatever, SQL, some backend language/Python/PHP/Java/C#, cloud operations EC2/Azure, Linux along with the many related toos like debugging etc etc. This sort of developer rarely comes up to mega expert level because they can't - they need to be very good at learning just enough to get the job done in a wide range of things. Likely they will have expert level in some of these technologies, but the point is that being able to dedicate your entire brainspace to only a few major technologies allows super productivity. The full stack developer is unlikely to be incredibly productive in one particular area.
The other thing that destroys my productivity as a full stack developer is hitting problems/roadblocks in some new thing that you need, but don't know well. This sort of thing can take days of problem solving, where an expert in that particular technology might be able to recognise and fix the issue in seconds. A good full stack developer must be very very good at problem solving because if you can't fix problems then you'll never get to write much application code.
On the other hand, a really good full stack developer should absolutely amaze you with their ability to build every single aspect of a large system including back end, front end, deployment and operations.
people who develop almost purely in one language, within a constrained application space, are able to become extremely productive because their knowledge and experience is very focused.
He mainly uses C and some JavaScript, but a look at all the things he's written suggests that he doesn't really focus on any one area; the first few projects on his page are:
- A Javascript engine (discussed at https://news.ycombinator.com/item?id=20411154)
- Neural networks
- Image compression
- Arbitrary precision floating-point
- JavaScript PC emulator
- 4G/5G base station software
- Tiny C compiler
- A clone of the text editor Emacs
- Pi calculation
My point is that there is enough information to be always learning in all fields you've mentioned.
If there are some out there who truly are of unparalleled execution ability, focus on testing, testability, reusability, modularization, componentization and simultaneously lifting up the team, I've never met one in my years in the industry. I don't think even if you spent 100 hours a week, you could achieve all of these things at once, so you have to compromise somewhere, and I know where people usually compromise. And that's before factoring in work-life balance haha.
In the early days of your company sometimes you do need people to just bang shit out, and eventually, you'll pay 10 1X engineers to clean it up. That period in a company's lifecycle is limited and the 10X'ers are outgrown very fast. Often they don't understand why but to their peers it's painfully obvious.
A story I heard from him recently came from a consultation with a team at unicorn that had spent months modeling a particular problem using a set of graph algorithms. For the past 3 months they'd failed to get the performance they wanted despite a great deal of effort. They brought him in and explained the situation, he realized quickly that the results they needed could be achieved with a simulated annealing style job. Three days after walking in the door he successfully implemented a solution to a problem that had stumped the entire team, in their area of expertise, for 3 months. His career is littered with such anecdotes.
Definitely a 10x engineer IMO.
I think one can only determine the productivity of an individual by looking at their performance over multiple years on the same piece of software. Otherwise it’s hard to distinguish engineers that are truly productive from others that are only fast at coding.
Now, as another commentor pointed out, some people can be brought in to solve a problem others cannot solve (simulated annealing solution, which I'll just say "oooook" to). Sure, there are individuals who can solve actual problems others can't, but those actual problems are very rare. Most of the problems I have are 'ship the product' types, not 'solve this one very hard problem' types.
So for me, the question isn't how productive one person is. It's how productive a collective can be as they work together, and how fast is the rate of improvement over time?
One of the common alternate explanations of 10x I've seen puts those people into the group: Adding a 1x person to a team results in +1 output for the whole team, while adding a 10x person to a team results in +10 output for the whole team regardless of how much that single person outputs on their own.
The business jargon for this type of 10x-er is "force multiplier". Whether or not they do a lot themselves doesn't matter, they bring the rest of the team up a level to where it's as if multiple people were added to the team.
If anything, that thread described cowboy programmers, not 10x engineers.
The fact of the matter is that the tech industry is based far more on collaboration and collective innovation than individual acts of anti-social genius.
He does exist, and when he was playing, he elevated the whole team. When he was paired with Pippen, it was amazing.
It wasn't just that he scored, but how the rest of the team responded.
10x engineers are like this. They are often good on their own, but pair them with a good team and watch out.
The question is simply what percentage of people in a given field are 10x, not if they exist.
One of them wasn't even super interested in development outside working hours - he just came to work, seemed to knock it out of the park and go home. I'm not saying he wasn't interested at all - he was mildly interested outside work.
Personally I’ve observed HN to have a pretty strong culture of tall poppy syndrome, which would explain that.
Essentially the real jerks are the sociopaths who try to bully everyone else into compliance and not upshowing them with their ability to actually do their job instead of wasting time on office politics. I'll take a whole team of surly coworkers over those assholes any day of the week but I have a strong and justified prejudice against sociopaths because they ruin everything they touch for self-advancement.
Certainly on Reddit, but HN seems significantly more meritocratic.
Most stories about exceptional achievement on HN will be met with all sort of anecdotal derision. “10x developers don’t exist”, “10x developers are sociopaths”, “10x developers are ‘brilliant jerks’”... other common themes are that people must have exploited others to achieve their success, or that their success is unreasonable because they made too many personal sacrifices to achieve it, or that their success is unfair, because not everybody has the same social skills as them, or whatever other ‘privilege’ people want to nitpick in order to deride them.
The original research in the 1970s didn't claim some programmers were 10x average, just that some were 10x some others. That is directly observable in any shop with more than a half dozen people.
There are "10x typists" too. I type 65 words a minute, sad as a typist but fast for an engineer. Our admin types something crazy like 170 wpm. People who never have a typing class can be 15-20 wpm. 170/17 = 10x. I'm sure a real typist would say 17 wpm people "can't type." From that person's perspective it's true.
What most people forget is that the 10x figure only measured those who completed the task. For any given task, there are definitely 0x devs and devs with negative velocity.
[0] https://twitter.com/skirani/status/1149302828420067328
I had an 18 month period where I was, essentially, a "10x" developer, and a "1x" contributor. My skills didn't radically change in that time period. What changed was the environments and teams I was in. I wouldn't be a '10x' in every team/environment, and I'm not sure that anyone can.
That being said, there are definitely people who have a knack for it and can learn fast, and also people who are just not cut out for it, period.
My weakness is I assume everyone around me is as open to (constructive) criticism as I am, and willing to learn from it. This proves often not the case. tl;dr I rub people up the wrong way. This reduces my worth.
Of course another explanation might be that
- your criticism is not constructive - your knowledge might not always be relevant - you might not have as much knowledge as you think - the incorporation of your knowledge might not be what's best for the organisation at that point (e.g. the time investment might not be worth it) - something else
There's no way to tell for us here, but do not automatically assume that the problem is other's willingness to accept criticism (or your ability to make them accept it). It might be the case, but it might not.
It always is. I never criticise destructively.
> your knowledge might not always be relevant
Then I expect to be told "no, you're wrong, here's why..." and then we can discuss, and one or both of us can learn something.
> you might not have as much knowledge as you think
Always true! However if the other can indicate areas of ignorance, I appreciate that and will go away and learn about it.
> the incorporation of your knowledge might not be what's best for the organisation at that point
I see my job as supporting the business. I happen to do that with technical tools, but that doesn't change the fact that I'm there to support the company because it pays my wages.
> something else
Probably I'm just insensitive/thoughtless and should learn to think before speaking. But definitely a fair fraction of programmers get defensive about their code.
Anyway, good points, upvoted.
1. an ability to avoid screwing around, procrastinating, implementing things that are fun rather than things that are useful.
2. innate ability to avoid yak shaving or dump it on others.
I had another friend who was also extremely productive. He never graduated from college, but he was a programming genius. One day he decided to learn ANTLR. Then he decided to deconstruct our query language for our product into ANTLR and discovered several bugs and inconsistencies in the implementation that made it impossible for ANTLR to parse it. Then I said "Hmm, it would be really cool to use ANTLR to read our XDR files and spit out some code that would implement the migration between versions." He said "great idea!" and accomplished that over a weekend, hand-constructing the grammar by hand. He saved the team probably 1 month of work every release cycle. He was absolutely astounding and the best programmer I ever had the honor of working with.
I'm managing developers and the ones who are most able to develop software aren't necessarily the most productive ones. I would love to know if 10x developers have simply a different mindset or in essence: What is their core skill that enables them to be so much more productive? Being focused, reducing things to the essentials and managing ones will power and time seems to be a subset of that "10x skill".
There's also a difference between a better programmer vs more productive. I will never be as productive as the two that I mentioned, but I'm pretty good at programming. I have enough experience to know how to develop a feature and a set of code such that it's easy to read, easy to maintain and doesn't have very many bugs. That's just something I've learned over time. Others may be much more productive than me, but I rarely have to revisit features due to bugs. So there are different measures based on what you want from a team.
That's a good point. Honestly, I would prefer a team of developers that are like you vs. outliers that are by definition hard to find and maybe even more difficult to manage. You sound above-average w.r.t your work ethic which is also hard to find and even more important for a strong development team.
> You can't get a 9-to-5 worker excited enough
Would love to know how to achieve that. I use psychological knowledge in my leadership and may have found a way to give people a way to show their full potential. But I'll make further tests before I write about it. Maybe you already have some well-tested tips - I found this infographic and liked it [1].
[1]: https://www.visualcapitalist.com/10-proven-ways-to-build-tru...
A 50k developer in 1980 should be making 260k today if they just following the growth of the economy.
The people that stand out to me aren't necessarily the ones who do what they're told. It's the ones who do what's effective.
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
“In one of their studies, Sackman, Erikson, and Grant were measuring performances 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!” – The Mythical Man-Month
https://10xfive.com/2018/07/31/origin-of-10x-principle/
And of course he didn't just point to the study, he just used the study to back up what he and many others knew. He also proposed a solution to the problem, the "surgical team", to get out of the idiotic situation of promoting the best programmers to no longer do programming.