“10x engineers”: Stereotypes and research | Hacker News Reader

“10x engineers”: Stereotypes and research

jasoncrawford.org

290 pointstosh267 comments

I've worked with many developers over many years.

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

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.

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 ;)

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.

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).

For anyone wanting to see the original comment: https://news.ycombinator.com/item?id=18996147

I remember this comment. I believe he discussed using a bloom filter.

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.

A lot of it is drive and people skills.

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.

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.

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.

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).

> 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.

> unless we're simply talking about people who are "productive"

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.

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.

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.

Agree with a lot of this except the claim that professionals dwell only on certain shores.

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.

It is already done in India and Ukraine. In Ukraine alone there are like 150k+ software developers.

If you lived in a $9/h region and had excellent development skills, why wouldn't you move to a $90/h region?

Because the $90/hr regions won’t let you.

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:

https://www.washingtonexaminer.com/37-percent-of-silicon-val...

> 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.

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.

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.

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.

You're comparing good / competent developers with developers who are either new or incompetent.

Being good at your job doesn't mean you're a "10x engineer".

Being good at your job is pretty much the definition of 10x developer.

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.

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.

Where did I say that 10X productivity means 10X more code? That’s pretty much the opposite of what I’m saying.

> 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.

> 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 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.

Both of these dynamics are at play.

You say,

> “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.

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.

I think we agree?

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.

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.

> 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."

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?

> I'm not convinced that every "10x developer" is solving software engineering problems on the same level at which Rembrandt painted or Bach composed

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.

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?

> 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 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 :-)

> 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.

[1] https://www.theatlantic.com/health/archive/2017/08/the-dan-p...

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.

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.

    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.

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.

>I am a developer, but only a 1X developer.

I've had the misfortune of working with a few 1x devs over the years. You would never encounter them on HN.

Or were they 0.1x?

I'm pretty sure I've encountered -1x devs as well, who contribute little and suck time from the rest of the team.

According to this article, a 1x developer is the least productive developer. So logically there's no such thing as a <1x developer.

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.

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.

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.

It's curious that no one ever talks about 10X times environments, 10X companies, or 10X management.

Nor about 0.1X environments, companies, and management.

So the question becomes, why are organisations able to accommodate some developers 10x better than others?

Yea

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.

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.

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.

> your criticism is not constructive

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.

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.

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.

We don't observe people removing all barriers for special programmers and letting them do whatever they want, which might be evidence it doesn't work.

Could it be because a complex system or project tends to be limited by its slowest/least productive necessary component?

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...

> 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.

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.

I find it fascinating you got voted down on what it essentially a pretty accurate description of how the system works.

Please follow the site guidelines when posting here.

https://news.ycombinator.com/newsguidelines.html

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.

Either reason for downvoting is illegitimate. This comment is sincere, interesting, and deserves to be readable by others.

Why are there no rockstar developers pulling in ten million a year?

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

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.

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.

Exactly!

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.

Yeah, some people are -1x developers. They create more problems than they solve.

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.

Those people are called testers.

That’s like saying messengers are responsible for causing any bad news they bring.

Testers are integral to situational awareness in any software or hardware project team.

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.

Agreed.

I think there is a bit of Dunning-Kruger going on too. The "architecture astronaut" variety always manage to introduce mountains of tech debt.

"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.

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.

One thing that I think gets lost in this conversation is the 0x engineer. I've met a few people who I'd put into this category and I've definitely met people who think of themselves in the 10x mold who I'd categorize as 0x. Ironically in my experience 0x engineers tend to be really good programmers, but they just don't know how to understand or don't care at a deep level what the business wants so they just build whatever is convenient or enjoyable for them to build.They get away with this on poorly managed projects led by non technical people. Eventually, deep into the project the non technical people start to figure out that the thing they are getting is going to be really poorly suited to their needs and by that time they are over commited and totally screwed. Zero or negative value could be delivered over an extended period of time here.

Compared to the 0x developer, a junior developer who gets a basic understanding of what is needed then solved it with a standard well suited tool is an infiniteX developer.

And there is a huge space in the middle here. But I'd venture a guess that all said and done, deeply understanding the problem space and client or business needs correlates more highly with total productivity than programming wizardry over the long run.

And don't forget the -10x engineer. The guy on the team who creates something others depend on, hasn't got the skill to fix its bugs and has the "well there's obviously nothing wrong with my code" personality type.

A -10x engineer wouldn't be capable of creating anything from scratch, even if they did they would likely have issues getting buy in from the wider organization for said code to go into production. They would spend their days engaged in the wonton destruction of previously stable applications, wasting the time of competent devs with incessant questions and ultimately creating a net loss in wider organizational output.

>A -10x engineer wouldn't be capable of creating anything from scratch, even if they did they would likely have issues getting buy in from the wider organization for said code to go into production

I have a two data points from a -10x engineer that say otherwise. They definitely do start things. The rest of us spend a decade making their mess a stable, workable system.

I've seen -10 x developers put in management positions. The company is now going under for obvious reasons.

I read this like 10 days ago and didn't catch the joke. Well played.

That's why we invented pair programming. As long as you have an even number of them, you are fine :)

You can take it up another level where the 10x developer goes over the project managers and gets a better understanding of the company goals directly from the decision makers. Then he becomes a 100x developer because he eliminates the communication overhead of the middle man.

https://blog.plover.com/tech/prudential.html

Sadly, I'd argue that there is also the -1x developer — someone who creates more than 1 bug for every bug they fix.

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.

> better programmer vs more productive

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...

Let me simplify it for you: pay them.

A 50k developer in 1980 should be making 260k today if they just following the growth of the economy.

I'd say it's a combination of raw intelligence, passion and ability to see a vision of how things ought to be and bring it into being.

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.

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.

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.

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.

I took an informal survey of engineers and most type 80+ wpm. 65 seems slow if you type as part of your job.

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.

Now here's a twist: Is that measured using the standard WPM tests (based on English sentences/paragraphs), or code like http://www.speedcoder.net/ ?

As an engineering leader, I can assure you that 10X engineers most certainly exist. I have seen them at play in the wild... (software and mechanical)

Step back from the tactical metrics and take a strategic view of an individual's contribution to team performance:

- % of major tasks completed within agreed-upon dates?

- # of emergency patches / roll-backs due to their code?

- # hours of management time needed for briefing & QA?

- % likelihood of exceeding expectations on design tasks

- % likelihood of expediting a major change successfully

- Support hours required for their code (zero is ideal)

- # team hours lost from dealing with random BS / drama

Look at your engineers; you will definitely see outliers. There will be an 80 / 20 in terms of who you should be watching and a handful that you need to let roam free...

This is like saying Michael Jordan doesn't exist.

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.

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.

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.

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.

Not sure what the proper origin of the debate on 10x was, and if it ever was talking about productivity. In my mind the point about the 10x developers had always been about the fact that some developers' VALUE (not productivity) is 10x. And in that sense it seems to me that the factor 10x is, if anything, an understatement.

A room full of 100 average physicists, or 1000 bad physicists, would never never have been able to make the contribution to physics that one Albert Einstein made.

And I think it's the same with developers. It's not rare to have a team of 10 developers with one individual whose creativity and problem solving ability means that the product that this team is building is better than any competitor's and that none of the problems that arise will stop the team's ultimate success. In this sense it might well be ONE engineer who is the catalyst for a chemical reaction that allows the other 9 to have an opportunity that sheer productivity can end up getting converted into value, the thought experiment being: If you take the team away from that guy, he could still build it by himself (but would take 10x as long, compared to how long it would take the team to do it). But if you take that guy out of the team, then the other 9 could expend infinite resources and would never get anywhere.

Your analysis might be sound, but I think your physicist example is off.

https://en.wikipedia.org/wiki/List_of_multiple_discoveries#2...

Ctrl+F Albert Einstein.

Many things in history are discovered very close to one another--suggesting that maybe 100 or so average physicists (not sure what this means though, most people who get to that level are extremely intelligent), would probably work out what Einstein did. People have suggested discovery is "inevitable".

"But if you take that guy out of the team, then the other 9 could expend infinite resources and would never get anywhere." This leads me to believe the physicist example is off here.

I think, in Physics, the key is not the discoveries, but the understanding.

It's often a single change in perception that unlocks a raft of related discoveries. Which also makes reasoning about such things hard, because once that perception shift has been identified, previously hard-to-understand things become easy, making the initial discovery look trivial.

That change in perception can happen from a small group of people or from a single person.

My take on this is, 10X what? What is the metric for code that we're comparing? Is it correctness? Speed? Reliability? Fault tolerance? Readability? Intuitiveness of design? Fast development? Someone easy to collaborate with? Excellence at debugging/fixing/refactoring code?

The best programmers I know are 10x better at no more than a couple of these metrics, while every coder expresses a different spectrum of credits/debits across the skill areas than the 'norm'.

Successful code itself seldom serves more than a couple of these metrics well. Fast code is almost never fault tolerant. Or readable. Or easy to refactor.

What's more, the creator of one 10x code is unlikely to easily shift his/her skill set ideally well to produce 10x code on a different project with very different priorities. What's more likely is that the 10x coder's next project will be implemented much like his/her last, regardless of whether the project's design criteria demanded otherwise. So across different projects, the same 10x coder won't deliver 10x results on all, even if s/he performs equally well on the same metrics -- because the design requirements have changed.

Like writers, programmers aren't good at adopting different writing styles for different roles or domains. The skills needed to design and write 10x code for an operating system or math library do not extend to a 10x user interface or social media app.

We really need to stop judging complex systems using single metrics. Oversimplification sucks.

10x+ engineers definitely exist within a given language and tooling stack. If they've got it all roughly memorized from top to bottom -- including all the quirks or pain points to avoid -- the ease of expressing a high-level use case in code like "I want the program to do X" becomes much more rapid. They typically also get it right the first time with very few bugs and cover most of the edge cases.

I have yet to meet anyone who is 10x+ across environments and tooling setups. It'd be like expecting a master mechanic from Ford who can do an engine rebuild in half a day to step into a Subaru shop and do the same thing. Highly unlikely. Probably still very competent, but not working at that 10x factor.

The thing is most programmers these days don't get the time to go deep into a given tooling stack. Or they do and once they've begun to achieve mastery the old stack is no longer popular or what the boss wants, or it's on to a new contract with different requirements that prescribe new tools, etc.

Absolutely no and this is again another myth. The engineers in top of their game are fairly independent of language and stacks. Learning required tools at accelerated speed is a hallmark of top engineers. Most of them often create new stacks and languages from the scratch. Here are some examples of 10x engineers: https://en.m.wikipedia.org/wiki/Coders_at_work. I don’t think they were 10X only for certain language or stack.

I’m easily 10x most of my team on my current project just because I’ve been living and breathing it for a year (and working on similar technology for a few years) and they’ve only been working on it part time until recently. It takes me half a day to do stories that take them a week or two weeks to do (same amount of story points assigned in sprints). I’ve just given up working on stories recently and have started pair programming because otherwise they’ll just all spin their wheels for days getting nothing accomplished.

I know a >40x developer. We started trying to get load of that single person, because they were heavily overload, were a single point of failure, and were doing so much that it was impossible for other people to grow new responsibilities.

We replaced part of that person with 2 teams of 20 people doing a small part of the work that this person was doing before. This person is still part of the two teams, in an advisory role, although they started as team leaders, but part of their job was now to grow new leaders that would replace them.

This person is still a >40x developer, still overworked, still doing way too much. Now we are trying to replace another of their responsibilities, with another 20 person team.

I'm pretty sure that once we do that, this developer will still be a >40x developer, just doing other things, that at some point, we'll need to replace.

FWIW, this person just does too much, because all that much must be done, and nobody does it, so they just take on it and do it, really well, and really fast. Most of this stuff doesn't even interest this person. There are some things that interest them, and that's what they want to focus and work on, but they still do all this other stuff.

So "replacing" them is actually something they want, but it takes time to recognize these problems, figure out how to solve them, grow people that can do the job, etc.

When I look at these two teams, and all the work they do, the only thing I can think of is wow, we didn't even know this 40x dev was doing to much. The dev didn't have time to complain, or write reports, or anything, because they were to busy doing all the stuff and putting out all the fires. It was only when they started saying that they would like to focus on this or that, and if we could find someone to take on this or that load, that we realized that no single person could take on these loads.

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?

> 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.

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.

maybe because you are the 10x

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.

Additionally, Brooks muses that "good" programmers are generally five to ten times as productive as mediocre ones.

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/

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.

Why doesn't anyone talk about compensation? Does 10x engineer gets paid 10x as well? Or taking 1x compensation is another feature of the 10x engineer?

One way that I approached this was to start my own SaaS product business.

First, it's a good way to test whether you actually are as good and productive as you think you are, since you now have to build an entire software product all by yourself. The ratio of deadwood at your company is going to be either zero or one.

But the nice part is that when you have one person at your company, you get to keep all the profit for yourself. And there's no reason to work 40 hour weeks (assuming you really are mr rock star like you think) so you only need to bring in say $10k/month and work less than 200 hours per year (1/10 of 2080, remember) to see an hourly rate that's more than 10X your 9-5 contemporaries.

Sorted.

Let's have everyone come to agreement about if those "10x engineers" exist in the first place (and seen as a positive :-P).

There are probably a lot of similarities to a "10x line cook"

I've worked at a few restaurants, and you want one of these guys during your dinner rush. With him, it won't even feel like the busiest night of the week.

It's amazing to see them in action. They're fast. They don't putz around. They don't screw up tickets, causing them to re-do their work. They do everything in the right order, keep their grill organized, keep their station in order.

The worst in the kitchen is a lump who gets flustered when they have more than 4-5 tickets at once, has an un-prepared station, screws up every 10th ticket...

> 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 still wouldn't call anyone who eventually completes a task given indefinite time to an unspecified level of qualify to be 1x.

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.

Listed under "what I believe" the author writes:

> 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?

Since it usually comes up in this discussion, Fabrice Ballard: https://bellard.org/

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.

Bellard isn't a 10x, he's more like a 100x.

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

What's more impressive than the programming aspect is the sheer depth and breadth of domain expertise.

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.

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.

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 love how programmer Twitter is in total butt hurt denial over this meanwhile Linus Torvalds created git in like a weekend.

I have no problem admitting that guy is vastly more productive than me. I don’t understand all the FUD.

It's also really dangerous. Maybe I am just really autistic, but I have a real difficulty comparing myself to others, mostly because there isn't enough reliable data available.

The funny thing is: If I don't compare myself at all to other people and just try to "be", I quickly run into problems: People find me condescending because I use words they've never heard.

So, I have to actually think about how smart I am, and how less smart other people are. If I factor this into account, and then engage people with the right vocabulary, I never run into problems. But ironically, this is actually condescending, but the audience never knows about it.

It's less good for me to describe myself as "normal", because actual "normal" people get "deranked". Society's asking me to see myself as the "smart" guy and act accordingly.

Honestly, I prefer to not compare and just be. I understand, or I don't understand, and I have no problem admitting either. I thought this was normal, but it appears, it isn't... in fact, some people would (maybe even literally) rather die than admit they don't understand something, and while most aren't this extreme, this kind of behavior seems to be the norm rather than the exception...

I guess it's more socially acceptable to not give credit and respect to 10x where it's due, because people probably expect these people to be so successful just the way they are, they believe they wouldn't require it.

EDIT: To come back around as to why this is dangerous: I've alienated most everyone of my friends and family in the process to learn the above. It would've really helped me if somebody just told me "You're damn smart, other people aren't, treat them like kids or something." Sure this sounds condescending, but read the above, it would've kept things not just for me, but more importantly, my friends and family, much more comfortable. But it's too late now, already.

EDIT2: In conclusion, talking to people requires active effort from me, and I find it very frustrating and annoying. So I prefer to be alone, and sometimes will be harsh, abrasive and arrogant in a preemptive effort to keep people away from me... My greatest fear is accidentally pushing someone away whom I'd rather not (there are people whose company I do enjoy), but if my logic holds up, that person should understand that...

I understand, or I don't understand, and I have no problem admitting either. I thought this was normal, but it appears, it isn't... in fact, some people would (maybe even literally) rather die than admit they don't understand something

This was a costly lesson for me to learn. Your general predicament has been referred to as The Curse of the High IQ (author Aaron Clarey).

Once you realize how much smarter you are than the norm, you realize that talking to someone of average intelligence is the same as someone of average intelligence talking to someone who is mentally handicapped. 2 std dev is 2 std dev.

Anyway I highly recommend Clarey’s book.

I have worked with -N (negative N) developers before, where the team would be N times more efficient if they were ejected, does this count?

Yes. The 10x number says more about your low performers than your high performers.

Original Twitter thread: https://mobile.twitter.com/skirani/status/114930282842006732...

The guy got lit by Twitter crowd for claiming that 10X devs exists, are introvert and often lacks deep empathy.

>often lacks deep empathy

Interesting claim. I'd wonder if this is based on measuring their ability at the sensing part of empathy, or the performative part. I'd wager the later, because they're already using "introvert" to mean "low amount of socialization in the context of work."

I enjoy socializing at work way more than I enjoy sitting at desk staring at a computer all day -- especially if I'm banging my head against a wall on an unrewarding task -- but that's not what they pay us for.

So the claim "10X devs exists, are introvert and often lacks deep empathy" just sounds like valley-speak for "10x devs exist, and are good at focusing on their job while at work."

His #3 way to spot a 10x engineer is that their "laptop screen background color is typically black".

This might be stab at people who use certain IDEs. Historically many IDEs were said to be designed for “morts” (aka enterprise developers on Windows) and “real” programmers supposed to be using heavily customized Vim/Emacs on Unix. Tools like Visual Studio, Delphi, IntelliJ etc had white default backgrounds which arguably strained your eyes if you worked long hours. In old days, black themed tools is what kool kids did at funky startups and white skinned tools is what tie wearing programmers did at insurance companies (this is obviously not universally true, but I think that was the perception).

For many years, most of these IDEs now have black themes and VS even now has it as default I think since 2015. Like all animals, we collect data (aka set of anecdotes) and build statistical model of word around us. Sometimes these models are hopelessly narrow, have too many false predictions and very quickly gets outdated.

I've been a 10x developer at various points in my career. If you connect with the project on a deeper level the code can just flow.

It doesn't last and you end up chasing this feeling.

It's easier to be a 10x developer when its your own project with your perfect setup.

I personally think high individuality productivity is related to

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.

There are probably 100x and 1000x engineers, but their true value can't be easily captured with any metric, at least not on teams and projects of non-trivial size and duration.

The value of an engineer is not what they did on a given day. It lies in the architectural decisions they make. Those decisions have ramifications over the following years.

I have seen "genius 10x engineers" make egregious architecture decisions (both micro- and macro) that have cost thousands upon thousands of employee-hours of lost productivity in the ensuing decades. Those developers were often regarded as "geniuses" and "highly productive" because they spent thousands of hours simply fixing the very problems they caused in the first place! Those same developers have also made a number of decisions that avoided similar pitfalls, thus saving the company thousands upon thousands of lost hours. So were those good engineers or bad ones?

Research that all you want, but I've never seen anybody propose a metric that would even remotely capture this sort of long-term net value created (or harm done) by engineers.

To even begin to answer this question, we'd need to take an extremely long view. We'd need to look at multi-year projects, the architectural decisions made, and somehow correlate them with outcomes. I'm not sure how you'd quantitatively define the success of a software project in the first place, much less map actions to outcomes.

Especially since the evaluation of software architecture decisions really involves comparing roads taken versus the roads not taken. Suppose engineer A chose language XYZ for a particular solution. Was it the right call? Well, what you're really trying to evaluate is the choice of XYZ against other choices that might hypothetically be made.

And, on top of that, engineering decisions are typically constrained by outside factors. Engineers often make bad decisions because they're forced to. Perhaps XYZ was an utterly terrible choice for the task at hand, but this engineer had nothing but a team of XYZ developers at their disposal. Management had a hiring freeze in place and deadlines were tight, making the choice of anything but XYZ nearly impossible. So how do you judge the effectiveness of that engineer?

I (like most people reading this) have made some absolutely disgusting engineering decisions in my life simply due to constraints like this. I once hardcoded several megabytes of data into a PHP array instead of using a database like a normal human being. This is, by any reasonable standard, a pretty awful decision. You won't find it in any books.

However, this was a very short-term project. The data was read-only. The deployment environment had no database available. And we were facing a deadline measured in hours. (This was before the days of services like AWS / Digital Ocean / etc making it easy to spin up a server stack) After a bit of testing I discovered my kludge didn't perform too badly after the first page load since I guess PHP execution plans get cached somewhere by some app servers. So I shipped it, the site worked, and we got paid.

Was I a 10x engineer there? Or 0.1x? Or 1x? I have no idea, and frankly the question itself seems silly.

My anecdote: I've been what one might call "10x" on some projects, and 1x on others.

In a position where I built the system/product from scratch, I'm the "10x" person. This is because I know the system's ins and outs better than I know myself. Of course I'm more productive with it. Of course I know exactly where to look when a bug arises. Of course I'm 10x better (across whatever arbitrary productivity dimension) than the new hire. It's not because I'm magical, it's because I was there when there was nothing.

Drop me into a new stack, with a new system, and I'll be -1x for at least a few months. Eventually I'll work my way to productivity, and that's fine. It's expected.

I think developer productivity has a lot less to do with technical skill than many people would like to think. I agree heavily with the article's points that "work environment matters a lot" and "productivity is a combination of inherent traits and acquired skills."

If you find yourself to be 10x engineer, you probably need a better team.

One way to do this is to find a better job.

Another way to do it is to put more effort into improving the quality of your current team. In the long run, that's a skill you're gonna need.

"Do not tolerate brilliant jerks. The cost to teamwork is too high." —Reed Hastings, CEO, Netflix

The 10x developers I’ve worked with have been some of the nicest people I know.

But what if they are brilliant team players?

I have to agree with another user named Amatecha higher up the thread who says:

>"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."

The problem here is with the definition. Most people don't define a 10x developer as someone who is a team player and more like the lone ranger you describe.

See this recent discussion on twitter: https://twitter.com/skirani/status/1149302828420067328?s=19

I've met some wizards. I'm not one of them and that's fine. I don't do any tech stuff once I'm home (I mean until my kids get into Lego mindstorms and such).

But I think being a 1x dev is pretty darn good when a lot of devs I've met are like 0.5x or even the occasional -x.

Literally the first bullet in the article's body says that there is no such thing as a <1x engineer. What am I missing in what you are writing?

I don't agree with the bullet. I've worked with people in the past who basically just didn't do their job if nobody was watching and would find ways to stretch their projects out to fill extra time. And I've met people who actively harmed the work environment and code. It's amazing how some people can get away with things and not be fired.

Which leads me to the feeling that if you come to work and consistently do an adequate job, I'd love to work with you. I don't need wizards on my team, I just need the basics.

Maybe it's not that there are 10x engineers, it's just that there are so many 0.1x engineers

As stated in the article, 1x refers to the least productive engineer – not the average one.

I don't consider myself a 10x developer, but I can be more productive than my peers on day to day tasks. The difference between me and them is automation. Stuff like executing scripts on the database, scaffolding new business objects I just execute a PowerShell script and its done. I focus a lot on productivity and keeping frustrating or boring tasks to a minimum and automation helps me achieve that.

But that only helps me so far, in areas where they have more business knowledge, unless it's an obvious thing, they have the upper hand, while I read docs to understand what is required or what might be wrong they already know.

https://dynamicecology.wordpress.com/2014/01/23/william-shoc...

This is specifically about academia and publishing, but I don't think that's all that different from a lot of development practice. It presents a useful way to think about engineer productivity that doesn't get caught up in meaningless slogans.

if the 10X is a comparison between the best and worst developers then there are 100X developers out there, during the early 2000s I once worked with a guy who spent a day wondering why his VBscript that instantiating an ActiveX object worked in Internet Explorer but not in Netscape. Yes, I or the other programmer in the office were more than 10X this guy, but I don't think it made us 10X developers.

Experience counts.

Some people seem to have 10x and more motivation to practice and learn than others. Why is it so difficult to agree that this is a major advantage? Because you can't have it delivered on a silver plate at any price?

From my experience; the biggest difference is knowing what corners may be safely cut, which code doesn't even need to be written.

I’ve hired a lot of engineers over the years who were better at engineering than me, but I can get 10x done faster because it’s my vision/passion and I work 80 hours a week vs their 40 because it’s my company (I am also full stack). So I say I understand the product and market 5x better and put in 2x the hours, which totals 10x.

Do you worry that your team will see you working 80 hours/week, conclude that they have to work that much too, and burn themselves out? Even if you can work that much without burning yourself out because it's your passion/vision/company, most people can't. It seems to me that employees often look to folks at the top to set the culture and feel obligated to follow along, even if that culture includes unsustainable work hours.

No, it's his company, if anything, I'd enjoy working for him. But only if my work contract clearly states that I need only put in X hours per week into work.

I worked in a startup, became the right-hand of the boss and owner, and then he'd slip into work only once per week. I did this for three years, my pay was... ok, but I didn't see the ability to develop any further or earn any more and eventually quit, and started my own company a few months ago.

I would've really appreciated if he would've done more, so that I could have focused more on actual technical work and not administrative or management work. Mabye I would've even stayed, I don't know.

Then again, I am very different than most people, so maybe this is just a very lonesome opinion...

Modern engineering is a social endeavor.

I do not discount the existance of more productive developers. But I do believe there's an ideological framing similar to the ceo cult personality. Also probably related to why you didn't consider a positive impact of organizational politics on productivity.

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".

The only way to become a 10x+ engineer is by enabling others to increase their productivity by mentoring, improving tooling and the overall environment, and making sure your team follows the big picture.

People are reacting badly to the idea of 10* engineers because it goes against the idea that we are all equals and can all make it.

I see it as a political stance, For some reason a lot of developers seem to believe in the idea of "equality of outcome" which means that we should all have similar outputs and if for some reason some of us are more productive it must be because of some systemic prejudice.

I personally believe that there are excellent developers out there. Some of them are brilliant jerks but some of them are also brilliant developers without being jerks. Those later ones are the real 10* engineers.

This is also how I perceive the 10x discourse. The Twitter thread - much more so than this HN thread - was quite revealing of this political/worldview aspect. Liberal views tend to encourage us to think that we are all equal and have the same opportunities. And obviously the idea that there are coworkers out that literally "10 times" as productive goes against this and receives a hostile reaction.

Just here to link to https://yosefk.com/blog/?s=10x

Not sure if I've met a 10x developer.

But there are 1/10x devs and managers for sure :)

...bring one into your team and overall productivity drops by an order of magnitude.

Dont forget -1x developers http://wiki.c2.com/?NetNegativeProducingProgrammer

There are definitely engineers who can solve the same problem using 10x the memory and cpu cycles of a really top-notch engineer... are these the mythical 10x engineers?

I believe in Gaussian distributions.

> we can’t say anything more than "roughly order of magnitude"

This, to me, is the core of it. "10x" is just a shorthand for the compound interest of good decisions. Nobody would be surprised to learn that teams with good managers are 10x more productive, or that factories with a good safety culture have 0.1x the accident rate.

Where it gets confusing is that developers have substantially more scope for compounding than their roles suggest. They're generally not managers, executives, or cultural leaders, and yet their decisions seem to compound anyway. Why is this?

For the answer, I encourage you to watch the YouTube channel "Primitive Technology", where a brave and often shirtless soul spends weeks and months constructing tools and structures from scratch. He does so with a deftness and skill that is captivating, yet the stuff he makes is, by modern standards, totally useless. It's not his fault; it's just that technology compounds, and no amount of individual skill can ever make a skyscraper out of wattle and daub.

Only in software, the most questionable of all the engineerings, do we build the processes and tools we depend on while we're using them. If you showed up to a job site talking about making your own concrete mixer to get the building done faster you'd be laughed right back to wherever you came from. Yes, in cutting-edge applications and prototype manufacturing it's different, but almost every other area of engineering takes stuff that works and uses it to make more stuff that works.

To be clear, this isn't a long-form argument for "we should have stuck with Rails", nor is it "software is just getting started, give it some time". Rather, I believe that software development is essentially and unavoidably compounding. Every design decision, abstraction, function and data structure is a piece of your foundation that you build and then stand upon to build some more. We're creating abstract machines, and when they become concrete enough to rely upon they no longer need software developers.

Which is why it's so ridiculous to imagine this 10^x developer who crushes code 24/7, laughs in the face of process or documentation, and communicates only via a colourful aura of cheeto dust and misanthropy. It's an adolescent fantasy of expertise, no different from Doctor House or Detective Batman. Sophomoric macho bullshit. The 10x isn't the person, it's the compounding effect of good decisions.

Peter Norvig is a great developer, but try airdropping him into some dumpster fire codebase that's 99% finished, riddled with bugs and way behind schedule. Is he going to grab his wizard hat and 10x his way out of it overnight? No. He's going to have to slog through the mess like anyone else. His expertise doesn't result in faster typing, but in better decisions. Decisions that work well now, but enable even better work later.

Most importantly, this kind of compounding doesn't just apply to you, but to the people you work with and the environment you work in. To enable that, you need communication, leadership and generosity. Here's the man himself, describing his work at Google [0]:

> I've varied from having two to two hundred people reporting to me, which means that sometimes I have very clear technical insight for every one of the projects I'm involved with, and sometimes I have a higher-level view, and I have to trust my teams to do the right thing. In those cases, my role is more one of communication and matchmaker--to try to explain which direction the company is going in and how a particular project fits in, and to introduce the project team to the right collaborators, producers, and consumers, but to let the team work out the details of how to reach their goals.

Or some quotes from his essay "Teach yourself programming in ten years" [1]:

> Talk with other programmers; read other programs. This is more important than any book or training course.

> Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you're the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you're the worst, you learn what the masters do, and you learn what they don't like to do

> Work on projects after other programmers. Understand a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain them after you.

Or check out his lavishly documented walkthrough of approaches to the Travelling Salesperson Problem[2] (just one of many similarly educational "pytudes"[3]). Or the leading AI textbook he co-wrote[4]. Or the online AI course he co-developed[5]...

That's what real 10x looks like. Not some myopic ubermensch who divides the world into "code" and "dumb", but a thoughtful decision-maker who treats great work as a garden to grow, rather than a race to win.

[0] https://www.quora.com/What-does-Peter-Norvig-do-exactly-at-G...

[1] http://norvig.com/21-days.html

[2] https://nbviewer.jupyter.org/github/norvig/pytudes/blob/mast...

[3] https://github.com/norvig/pytudes

[4] http://aima.cs.berkeley.edu/

[5] https://www.udacity.com/course/intro-to-artificial-intellige...

mmh. my keyboard looks like his :D

This is coming up b/c of the 10x engineer tweet from an Accel Ventures VC. This is how they defined a 10x engineer/what to look for in order to spot them:

- They hate meetings (doesn't everybody?)

- They keep irregular hours

- They use a black desktop background

- They wear out the i, f, x keys on their keyboard instead of a, s e (the latter 3 are apparently correlated to sending lots of emails somehow)

- They know every line of code and can therefor immediately trace back any bug in prod to the exact line of code

- They are full-stack engineers, code is code so they can do everything but they won't touch UI

- They convert thought into code by caffeine fueled code binge sessions in which they implement any product feature over the span of 4-6 hours

- They rarely if ever need to rely on documentation

- They are always using the latest and newest tech

- They are poor mentors and interviewers b/c: They always think "It takes too long to teach or discuss with others, I would rather do it myself."

- They don't hack things, they write quality code and know exactly how the code needs and will evolve over time

- They rarely job hunt or move out of a company

https://twitter.com/skirani/status/1149302828420067328

I can't even begin to comprehend how some of these are in any way an indicator of a 10x anything.

Keep that in mind as you read through this post.

What garbage.

EDIT: utter and complete garbage

Surely this is not written by a developer?

Update: https://www.linkedin.com/in/kirani/

The person who wrote that tweet is not a developer.

The conclusions this VC has drawn about what makes developers productive is Voodoo.

He's observed people who he thinks are productive, and gathered together his observations/prejudices/misjudgements about those people and concluded that the Voodoo is the magic. I'm sure there's some great analogy out there about drawing conclusions about how something works based on misunderstood observations, but I can't think of that analogy.

Correct, they're not a developer. They doubled down on it too: https://twitter.com/skirani/status/1150019060467240960.

Dang it ... and I had already changed my background to black and sanded down my i,f,x keys with a Dremel.

This isn't a guide for identifying 10x developers. This is a guide to identify suckers. Something which is in the interest of a VC.

> They rarely job hunt or move out of a company (and all the other bullet points)

means

> Exploitable human being that is socially unadept, impatient, unsecure about their own self-worth and so difficult to manage that competitors won't recognize their business value so you can lowball them easily

When I was young and foolish, I wanted nothing to do with UI either. Then one day I woke up and realized that to the user, the UI was the program in its entirety. Everything lives and dies by the UI. It doesn't matter how wonderful or sublime your code is if nobody can operate it.

I don't think you can be a 10x engineer until you realize this.

What do you need to do to be this clueless yet make lots of money and be put in a position of responsibility?

The same thing you need to do to make lots of money and be put in a position of responsibility anywhere (whether you're good at what you do or not).

Be good and convincing people they should pay you lots of money and be given a position of responsibility. Either by being a good enough at communication that you can convince people your work is good whether it is or not, some kind of nepotism/social proof, sheer luck, or some combination of the above.

There's also actually being good enough that your work speaks for itself, but the OP asked about clueless people.

> instead of a, s e (the latter 3 are apparently correlated to sending lots of emails somehow)

At least e,t, & a are the three most frequent letters in english. I guess S is for a hotkey or something, idk where he pulled that from.

I'm similarly baffled about the the i, f, x thing. I can think of justifications but they're all pretty dumb. I'm pretty sure that whole bullet point was based on exactly nothing this guy's ever seen in real life.

I assumed i and x were because they are the most common variable names in loops, i and f are used in if statements. So he is saying these guys write lots of loops and if statements - I am not going to write a conclusion here because I am trying to lay off the cheap wit.

I thought the "i" was for "insert" and f for "find" (that i use a lot to move quickly in a line in vi/spacemacs). But i am wrong, and realising made me smile a bit.

This is BS though. I used to work with "10" devs (more like 2 tbh) and the only way to be at their level is to: - Have a lot of creativity and nerves (because sometime you have to "hack" something in a really short time). They can be 10 in this case. - Know your tools and your product really, really well. - Be on point on everything surrounding your product: basics on GUI, network, hardware, security and crypto (even if your basic on crypto is "do not run your own crypto", its enough).

Also the 2 10 i met were not jerks, and one i only talked to via skype was just a bit arrogant but nothing unsufferable, so to me it is a urban legend.

I think that 10x engineer streotype is ridiculous but the backslash in the Twitter is also discouraging. Most of the responses in the Twitter reject that 10x engineers exist. Some even go far like creating this website: http://10x.engineer/

But there are people like Linus Torvalds, Fabrice Bellard.

I think we need to hit the right balance. We don't want to worship 10x engineers but we don't want to limit the potential of the engineers by saying 10x engineers don't exist.

Agreed, those two are famous programmers standing on the shoulders of giants with their software being used by all companies in the tech industry.

If people keep believing this legend, then Newton, Babbage and Turing are also 10xers then.

If they are so good why will they refuse to look for better opportunities by not moving out of the company?

Sounds like it's written by a Hollywood script writer.

This must be satire.

Did you know that there are also 10X venture capitalists?

Here is how to recognise them:

https://twitter.com/bootrino/status/1150560676890329089

Somewhat OOTL but why was 10x engineers trending on twitter? I've seen a few references to it but no idea why it started trending

This tweet[0]. People then made endless parodies of it.

[0] https://twitter.com/skirani/status/1149302828420067328

Jesus.

One reason to deny the existence of 10x developers is that some organizations intentionally handicap their developers such that processes prevent anybody from being productive. This can occur when the organization, or the developers compromising it, do not trust the developers. It is hard to trust anything when a body of developers is functionally illiterate in their primary programming language or when the primary development goal is always achievement of easy.

> One reason to deny the existence of 10x developers is that some organizations intentionally handicap their developers such that processes prevent anybody from being productive.

So because some developers work for awful organizations, 10x developers cannot possibly exist anywhere? Not following that logic.

That is absolutely not what I said. You took part of what I said out of context to fulfill a maximum strawman.

That's how I read it to. I don't think he straw manned it??

> Why people claim 10X developers don't exist surprises me

Personally I’ve observed HN to have a pretty strong culture of tall poppy syndrome, which would explain that.

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.

Really? On hacker news?

Certainly on Reddit, but HN seems significantly more meritocratic.

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.

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.

Definitely a 10x engineer IMO.

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 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.

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.

you describe net negative engineers not 10x engineers.

I'm describing the engineers I've encountered who have been dubbed by others in the business as "10X".

Reply on news.ycombinator.com