Hacker News Reader

Comment by andrewstuart | Hacker News Reader

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

View on HN

I think the ability of a programmer to be 10x or 100x or 1000000x depends on the domain. If you are writing a sales tax calculator and need to implement 500 different local state sales tax regulations from a scanned Word document, your best developer is going to be maybe twice as fast as your average one.

But if the problem domain is “write a program to search the Web” or “write a program to allow people to send data-plan messages to each other from even very old feature phones” then the best developers can create millions of times the value of an average programmer.

I was just thinking about how at most jobs I've ever worked the main barrier to productivity is the inability to make minor (in my opinion) changes to organizational policies that have high business logic complexity relative to benefit.

Yeah. Particularly if you don't have the authority to implement changes that would improve things in the long run, there's really no way for a dev to be a "10x" in that situation, even if they may have the ability to be a "10x" dev in other contexts.

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.

Yea, I’m surprised how rarely domain comes up in these discussions. And, as you say, it’s quite obvious that knowledge and raw intelligence can give you far more than a 10x advantage in some domains.

For an extreme example, imagine that the year is 1993 and the task is to write a program that produces a proof of Fermat’s Last Theorem... My bet is that a certain “developer” named Andrew Wiles would have wastly outperformed a ”team” consisting of every other person on planet earth.

I'm with you on the domain topic; reading the extreme example I'd add repeatability of the performance (on a different problem of the same domain) as an equally important factor to distinguish the developer from the inventor.

oooh oooh oooh, what an interesting example! I recall an interesting comment on NH a while ago where the dev was describing their refactoring of some law code. The original code was if-then-else, and had the same 'shape' as the horrid law it was interpreting. Our intrepid dev redesigned it to use some kind of truth table instead, and was terribly proud. And then the next week the law was amended and a new clause added deep down in one subclause or something. It turned out that the clever algorithmic approach wasn't actually the most maintainable... So, using a sales tax calculator as an example, its possible for two different devs to take to completely different approaches, and for the betterness of one or the other to be in the eye of the beholder until the code has been maintained in production for a long time, by which time doubtless whichever approach was adopted is deemed to be the worse one as the other has no production experience so might be better ;)

I learned a few years ago that there are laws in the UK, parts of which are written in a naturalish language dialect of some complicated proprietary Oracle product. There’s a productivity gain for you (if you’re an Oracle salesperson at least).

Honestly, adding legislature into code is a losing game. Let the developer just deliver a flowchart engine so that even unpaid interns can get to modify the logic.

In my opinion, a whole part of being a productive developer is about empowering people without the technical chops. If someone getting paid 10% of your salary can complete your previous responsibilities, you're technically a 10x developer.

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

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

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.

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.

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

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.

I don't believe that the majority of comments on Twitter are trying to say that every developer is as as equal as every other. Many of them are arguing that the "10x developer" idea is unrealistic in the sense that management wants to hire someone 10x more productive than everyone else (this story agrees, 10x is a big exaggeration). Some people have worked with so-called 10x developers, who have been slavishly defended from criticism by management, who are churning out piles of code that will be difficult to maintain, it seems that some of those people also have some toxic behaviors.

In terms of the question "do 10x developers exist", I wonder if it really matters. An argument has been made that there are people far better at chess or football or piano than everyone else, so there must be developers who are vastly better than the average in the field. I'm not sure that software development is really the same kind of thing... But even so, we do not have the systems in place that would allow us to recognize such people. All we have, for the most part, are anecdotes from recruiters and managers and many of these stories sound self-serving and exploitative.

It could be the 10x developer exists in the same sense that the 10x CEO exists: every so often one appears and seems to meet the standard. But the closer we look, the more circumstance and the people they surrounded themselves with seemed to be even more important. Often it looks like maybe the particular period of time was a factor as well. And the argument goes on and on, so on and so forth.

That's a more generous reading of the mood on Twitter. I also think that many people have good intentions, and are only trying to reduce the general levels of impostor syndrome.

> Some people have worked with so-called 10x developers, who have been slavishly defended from criticism by management, who are churning out piles of code that will be difficult to maintain, ...

And I have experienced this anti-pattern several times. But I worry that we're throwing out the child with the toxic genius bathwater.

> 10x is a big exaggeration

The actual actual factor is a function of your work environment. If HR hired "nice" people who failed all the trivial interview questions, would that number still seem unbelievably high? That's what some small shops do when developers are hard to find :|

Fair enough, once there's more than a handful of replies a Twitter thread turns into a trash fire. The replies and posts that I have read, insofar as I had patience to read them, struck me this way.

I don't think any organization has the ability to hire exclusively 10x developers, even if they did exist. Large places with deep pockets can afford to hire many people and then promote those they perceive as meeting their own idea of what a 10x developer might be.

On average, I think everyone should try to hire the best people that they can. Companies should try to retain their best people and encourage everyone to improve. Over time, the productive people will emerge and should be valued by the organization. Are they going to be the mythical 10x developers? Maybe, maybe not.

This idea that you can hire a 10x developer to guarantee the success of your project is, in my opinion, a waste of time and money. If you think it's working then I bet technical debt is piling up and it will catch up with the organization eventually.

I don't know about 10x, but the most productive devs I meet are usually the TDD kind, because they don't create as much technical debt, they are faster.

My first team lead was a 10x developer; I still remember searching for the j2ME code that would have taken us two weeks to complete that he wrote overnight -- I remember how dismayed I was to find it all directly in the keyboard event method instead of being spread over to various places it should have been.

So his initial code was a "10x" achievement, accomplished in literally 1/10 (or less) of the time it would have taken the team.

....but the legacy of his "10x achievement" was an increased maintenance burden. So the overall gain was less than 10x. Perhaps it wasn't even a net gain in the long run.

This is a good example of my main beef with the whole "10x" thing. So many superstar developers are lauded for banging things out quickly, while everybody else is stuck cleaning up 10x the mess.

I truly believe that there are 10x developers, but identifying them is nearly impossible unless the person doing the identification is (a) a pretty savvy developer themselves (b) is intimately familiar with the choices made by the "10x" dev and their long-term ramifications.

> But I have never seen one that can do that _and_ produce quality.

I've never seen a mediocre dev produce quality so it isn't needed in order to be 10 times as productive as a mediocre dev.

What I think usually happens is that the 10x dev produces 10x as much technical debt as everyone else, so the team thinks that this guy is blocking all of them when it would have been just as bad if they put 10 mediocre people to do it instead, just that then the blame would have gotten spread out among 10 persons.

Or he produces 10x the quality and 1x the code of everyone else, but his mediocre colleagues doesn't notice that his code is better since everyone else added so much crap so he is seen as just a decent 1x dev.

I think this is a great way of looking at it. Coming from the product side of things, I see developers who are vastly more productive than their peers because they have amazing organizational and communication skills. They help keep timelines on track, they keep their peers focused and identify potential issues that a PM without an engineering background might miss. Developers who can suggest small modifications to a product spec that will drastically reduce development time but not greatly impact the overall product are worth their weight in gold.

This perspective saddens me because you’re not describing a productive developer, rather just some employee good at acquiescing to what product managers (often mistakenly) want.

10X developers aren’t wasting time debating scope with product managers. They are too busy doing things that directly help customers and stakeholders, generally as a direct result of flippantly ignoring what product managers say and the ensuing politics over who gets credit and what is politically allowed to be shipped.

One way to spot a 10X developer is that it’s someone getting lots of stuff accomplished despite product managers finding it universally frustrating to ask that person to take on the product manager’s agenda.

Honestly the reason why these people are so rare is not because they are too hard to find. It’s because product orgs can’t tolerate someone whose judgment supersedes their own in regards to what the customer wants. The 10X developer does product management circles around product managers all while getting their own software jobs done in the meantime.

In order for there to be possible options for politically arguing over bonuses & credit for what is shipped, you have to staff most of engineering with passive people who don’t push back on product management, hence very few 10X engineers.

Sad that people downvote without bothering to reply. To me, it sounds like you either don't like your product team in general, or they ignore your ideas for reasons of territoriality, or you're doing a bad job expressing your concerns to them.

Frankly, I don't see why an engineer would know what the customer wants better than a product manager. I do see how an engineer would know the kind of corners they most want to cut, and of course how any human would want to present their self-interest as the group's interest, but I don't know anyone's specific circumstances.

> “Frankly, I don't see why an engineer would know what the customer wants better than a product manager”

The engineer usually spends much more time investigating customer usage data, help center feedback, product features and competitors, all while also having greater familiarity with the engineering implementation (to know what’s feasible / reasonable) and greater quantitative skill to determine the implication of evidence in terms of what actions to take.

One lesson I learned a long time ago is to develop product management as a career growth track for engineers who are interested, because the best way to be an effective product manager is first to be an engineer of that product for a long time and leverage the engineering skill set as the primary skill set for product management.

I've met great engineers who were great at driving product, and great engineers that were terrible at it, or uninterested in it.

I've met engineers who could invent a whole new product out of sackcloth to solve a customer need the business was only dimly aware of, and engineers who used all their knowledge of customer pain points and data to fritter around the edges of their systems, redesigning this or that but making little material progress in addressing serious issues.

I have little time or patience for "engineers > PMs" arguments or vice versa. You should be a team working together to solve important problems, and you should each recognize and celebrate the skills each of you as individuals brings to the table. If you're not doing that, the problem lies with your team or organization, not the profession as a whole.

> “I have little time or patience for "engineers > PMs" arguments or vice versa.”

But some skill sets are more effective at some tasks. You wouldn’t hire a stand-up comic to play quarterback on your football team. There are opportunity costs to doing so that make it a strategic blunder.

It’s really the same, only lesser in degree, when thinking about what sort of background & skill set someone should have when you hire them to manage your product development.

If you narrowly dismiss that consideration by acting like every skill set is equal & every type of person hired into the position of product management can do the job, it’s no less of a strategic blunder.

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.

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

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.

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.

There are also people who are simply better at the job no matter the conditions. Bach was a 10x composer, Rembrandt a 10x painter, you could train as hard as you can for your whole life chances are you wouldn't even be close to match their skills.

imho people tell themselves 10x don't exist because it's hard to admit some people are just better. Especially in our industry in which a lot of people confound "work title/achievement" and "identity".

No, you can definitely beat Rembrandt's skills if you spend your whole life doing it as hard as you can. This is why you shouldn't use 10x label, it is wrong and goes against everything we know about the world. It merely tries to put down people, convince people that they simply can be bad at the job, which cannot be farther from the truth. People are just different, have different backgrounds, different experience, different skills. Which means depending on circumstances some people have to learn new skills and start figuring things out from scratch, while some could already be years ahead. This is important, as even the most unmotivated, unhappy, skeptical person in the worst conditions, but a domain expert of a big complex domain will still do a better job, than someone who needs to spend years before even starting doing the job.

Anyway, 10x label is harmful and disrespectful. But I guess this is true for labeling people in general.

> This is why you shouldn't use 10x label, it is wrong and goes against everything we know about the world.

Are there studies that prove that everyone can master any skill if they try really hard? This doesn't match the anecdata I've experienced and seen [1].

> Anyway, 10x label is harmful and disrespectful.

Yes, if we decide that humans are only as worthy as their code. But we can also consider, even in the age of neoliberalism, that economic activity is a tool, not our purpose. Some are more productive than others, so we need to help each other out.

Conversely, if we assume that talent does not exist and everything is just a matter of trying really hard, then the conclusion is that poor (able-bodied) people are simply lazy and deserve their fate.

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

> People are just different, have different backgrounds, different experience, different skills.

Yes, and if these things make you perform ten times better than your colleagues then you're a 10x. We don't judge people by their hypothetical potential (well actually we do, for a short while), but by their current performances.

It'd say it's more disrespectful/harmful to say that everyone is a Bach, a Rembrandt or an Einstein. It's not just a matter of studying and working, everyone hits a wall a some point, some way earlier than others. Your will to be better isn't enough.

Labels are not harmful as long as they're factual. My light bulb is less bright than the sun, I'm not as good as a painter as Rembrandt, that's the human condition and we have to accept these things. Saying they're harmful and that everyone can become anything they want is a fairytale.

Bach and Rembrandt were artists. Most companies are looking for 10x developers to write systems to manage billing, accounts, inventory, etc. I don't see how we can compare Bach to someone toiling away on a better business software in any reasonable way.

If there are developers out there doing work on the same level as Rembrandt or Bach then they are working in an entirely different domain. Personally, I don't think we have the ability to recognize these people and, if we did, there is no guarantee that their work would be applicable to business systems in the way that the "10x engineer" myth implies.

Isn't it a fact that software engineering is inherently creative? While programming may not strictly count as art by most people's definitions, it is certainly not soulless or mechanical as your comment implies. In particular, Bach's music is so remarkable precisely because it combines mathematical patterns and subjective beauty.

I hate the phrase, but exceptional software engineers "paint with code."

> Isn't it a fact that software engineering is inherently creative?

Yes, absolutely. If you can create a simple, clean, extensible abstraction that hundreds of other engineers use to avoid recreating and testing functionality this could be considered 10x due to the leverage.

I agree that software development is creative, I do think that's an important part of the process. I'm not convinced that every "10x developer" is solving software engineering problems on the same level at which Rembrandt painted or Bach composed.

It seems to me that painters and composers create art that is appreciated much more widely and over a much more varied audience than software engineers. Given that the inner workings of software are visible to a much smaller audience, isn't it likely that their skills are being over-rated?

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

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

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.

I think this perspective is totally underrated. When I compare a lot of people's careers I see these dynamics jumping out at me a lot. Timing timing timing. Autonomy too. When you're decent at what you do and you're allowed to do it, it turns out you can do good things. When you do good things you get more of the right kind of experience. Gaining that experience is rare in the first place thus making you even more rare and valuable (in the right context).

I'm glad I'm not the only one out there that sees it like this.

    Carmack was also given lots of power and free reign, another 
    aspect of being a 10x+ that is key. If something needed to 
    change to make them more productive, he was the architect and 
    was allowed to make it happen. That access is harder to obtain 
    on established teams

Yes. This is so key. This is why I (and many others) bristle at the "10x" stuff. It's so context-dependent.

Put John Carmack to work on a legacy maintenance program at some bank where he's not allowed to make any real decisions that affect the workflow or overall codebase, and that guy's no longer a 10x programmer. He's not even going to be a 1x programmer until he learns all of the archaic domain knowledge relevant to his new, miserable job.

Lots of people are stuck in situations like this: 10x (or 1000x) talent stuck in situations where they're performing at 1x or worse.

Likewise, lots of people with 1x talent are perceived as operating at 10x levels relative to their peers in the organization because they've got favorable circumstances: they're allowed to work on greenfield projects while others are stuck doing maintenance, they're allowed to choose tools and stacks that suit their own preferences and skillsets, etc. Or they're the ones that wrote the initial code and are the only ones who really understand it.

I've been in both those situations, and others.

At various points in my career I've operated at 1/10x, 1x, and 10x relative to my peers.

It sure wasn't my work ethic or talent that changed.

Now, some may say that part of being a "10x" developer is striving to put yourself in situations where you can actually be a 10x developer. Well, if folks want to define it that way, then sure. But that sort of presupposes some kind of ideal free market in which people are free to change jobs as often as they like until they have found their own personal little 10x niche. Certainly we all should strive to do that, and many of us do, but there are significant barriers to doing that.

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

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.

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.

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

Yea

Reply on news.ycombinator.com