At many places, the best thing that can happen to a manager is for their team to become "too big". Oops, now they have to split it into two teams, and suddenly they're a Director instead of a Team Lead (or whatever titles are used).

That's interesting. Not the total compensation of the people she manages?

And so, off we go to empire-build. It's a pretty hard impulse to resist. Especially since many places consider "growth" the ultimate goal.

- they didn't work well with others and soaked up a lot of management time dealing with their shit.

- they had really limited areas of expertise where they were amazing, but couldn't fill in for a sick colleague.

- they worked in 2-3 day sprints for ridiculous hours, and then stayed home or might as well have.

I'm sure there are incredible people out there who can 10x and also be great team members, and I'm sure management are idiots if they don't pay them 10x.

But in my experience, the people who claim to be 10x are usually just insufferable egotists who have no idea of the pain they cause for everyone else.

A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance.

The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work.

Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]

I think too much faith is put in the abilities of most management; otherwise this Ask-HN article might not have been asked.

Probable examples of 10x, Steve Wozniak for Apple, John Carmack back in the day, Dennis Ritchie, Tim Berners-Lee, Jeff Dean.

If you aren't getting 10X output, it's possible that the problem or situation you have placed the person limits them to less than 10X.

I do agree that there are far more people who claim to be 10X than that there actually are and that many come with costs.

Also it is simplistic to claim a person is 10x. A more accurate measure is seeing a 10x effect. Writing key software that saves a company or gets a company bought is a 10x effect. I've seen that happen several times.

Otherwise, I am a thoroughly mediocre performer. I'm a minimum effort Loser[1] all the way.

[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

I think the -1x programmer is even more common, the ones that have negative productivity and actually create more work for other programmers. I've encountered many of these types over the years.

They are usually the very hard working type too. The kind who when encountering a problem always solves it by piling on more code, never refactoring, never taking a step back and thinking about the problem. You don't want to be seen idling at your desk, better keep typing.

I've had days where I've ended up doing literally nothing, but still objectively outperform some colleagues because they rammed some shitty unstable undocumented race-condition hack into the codebase.

In my experience, the '10x' programmer is not necessarily more productive (as in amount of work done in a certain timeframe), it's that the 10x programmer does better work, resulting in time savings down the line. Fewer bugs, a more flexible architecture, etc. It can be the difference between being able to easily add a new feature in version 2 and having to rewrite half the application.

The other points you make might be big problems depending on the situation, but this? What's wrong with someone taking a day off after a burst of productivity? This seems like classic valuing of face-time over results.

The "10x" works 16 hours a day for 3 days and produces a chunk of code that works, does what it's supposed to, ahead of schedule. So far, so awesome.

But the rest of the team is working away on the rest of the project. Suddenly they're lumped with a huge chunk of code that they don't understand. They weren't involved in the design decisions, they didn't pair-program or brainstorm any of the code. It's pretty impenetrable. And the "10x" who wrote it is now unavailable after that "heroic" sprint so they can't even ask questions.

Teams work together. Heroic sprints of productivity followed by absence is not working together. It's leaving other people to clean up your mess while you claim the credit.

Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time.

Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..

1) A very small amount of code

2) Isolated from everything else

3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious)

Most people would kill for a colleague who wrote code like that.

No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins.

Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.

I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.

This is a well known major impediment for creative persons in any field. You can explain things after they are done, not while you are doing them.

This is why average developers create such a drag on productivity. They always want meetings, explanations -- in short, anything that slows down the work horse and make them look productive in the process.

It's at least a unicorn, so companies shouldn't worry about hiring any 10x developers because they are THAT rare.

What they should do is avoid the developers that actually cost productivity. I'm a 10x developer compared to someone else not because I'm 10x average but because there is a 1/10th average dev there.

I'd say try to find the people who are just way over average (2x devs) and pay them twice the money if necessary. The problem is finding these people and making sure you aren't paying someone average twice the pay.

I think it depends on Industry / Role. A creative person in Advertisment or a good chip design engineer or someone great with Algorithm are often worthy of 10 or 20X compensation. Whats wrong is that many people think 10X guys can exist on Application layer / Front end. I think its very hard to do that

Of course it's hard to be 10x there. The same way it's hard to be 10x on the algorithm side. It's also a matter of scope - if you have a giant backend, and your frontend is a single text box, it's hard to tell if somebody is 10x. As the FE scope grows, you start seeing the differences.

In my experience, 10x programmers are hard to manage, they complain all the time, no one wants to work with them, their ego gets bruised easily.

But you keep them around because they seem really smart until you look at overall work produced. They might produce 10x work over a weekend but over longterm, they hardly produce any more work than average programmer.

In my interview process, if anyone even slightly hints that they are smarter than average, I end interview immediately. My team is composed of average programmers who get along and have fun working together.

I heard a joke once : Complicated problems requires complicated solutions. Unfortunately, all problems are a bit complicated if you are a bit thick.

The gist is that complexity grows faster than it needs.

Ignoring people that can't make things over a certain threshold, there is a large group of programmers that can make things work, but are not able to build things clean enough or put in the effort required to build testable and maintainable code, simplify support and reduce runtime costs.

Knowing when to stop and what to spend some extra time on is also important.

I'll hesitate to add reducing future development costs, because I've seen too much overly complex code written in a misguided attempt to handle unknown future requirements.

All these costs can easily build up to 10x over time.

A factor is that a team probably smoothes over the effects of one or two bad coders in a way that it's not noticeable at short term - the code is delivered and the worst bits are plastered over, but the long term performance is reduced.

Preferably the requirements are explored by the team with the stake holders.

The 10x effect is not on the immediate output of a particular development task. It's the lifetime value/cost of the choices made. In this respect there are many 10x developers, the ones who can factor complexity into a composition of conceptually and realized simple components. This works if they're presence is early in development, otherwise you may need a 20x to turn a 1x codebase into a 5x one.

Here in New York, this is especially acute. Many finance companies have thousands and thousands of developers. They'll have a team of developers (costing maybe $500k/yr total) working on a problem which a single excellent developer could easily accomplish (and be happy with $250k/yr).

Tons of companies are penny-wise and pound-foolish, mostly because programming is still considered a low-status profession.

> Until "management" realizes this, the only way that a developer on the upper end of the productivity scale can capture their value is to found their own company. I sometimes wonder what would happen if some company simply offered to pay 3X the market rate and mercilessly filter the results.

There are companies which do this, but they're almost exclusively pure tech companies (ex. Netflix).

Management doesn't want super-performers, because they can upset the power dynamic.

Developers must have lower status than management, and super-performers can challenge that.

Companies are actually social networks. Instead of gaining status by posting selfies of yourself in exotic locations with cool people, you gain status by making high status noises in emails, talking in a high status way, having many people reporting to you, and having equity.

Sometimes getting things done is relevant too, but not as often as it should be.

For me, it's actually not about the compensation for its own sake. It's that compensation is a strong signal of how the company thinks about the status of developers.

3 average programmers who understand your code adds a lot of redundancy.

And as an interviewer, it is really hard to identify who is 10x and who is not. But very easy to tell who has enough knowledge and pleasant personality. Programming in most companies is team sports, not a marathon.

There are tons of companies with thousands and thousands of engineers who could easily make do with 100-1000 engineers if they were willing to attract and retain top talent.

> And as an interviewer, it is really hard to identify who is 10x and who is not.

That's definitely true, but top companies manage to do it. And when they make a mistake, they rectify it.

Team sports still pay to attract top performers. The best players can be a force multiplier for everyone.

I know many programmers from FB, Google, Amazon, Apple. There is no way they are 10 or even 2x. Some of them I worked with too, so I know their work. Others are just friends, we discuss technology all the time.

> Team sports still pay to attract top performers. The best players can be a force multiplier for everyone.

You are right team sports do pay a lot of money for top talent. Unfortunately, my experience with 10x programmers, as a teammate and as a manager, has always been negative. Most of them barely produce more than average programmer on long run but demotivate entire team or department by their arrogance, talking down, complaining, rudeness.

https://news.ycombinator.com/item?id=15033386

Seems like management is damned if they do and damned if they don't. If they reward high performers in proportion to the value they generate, they kill the culture of the company. If they reward everyone fairly & equally, then all the high performers quit.

Full employment theorem for entrepreneurs, I guess. If management is rational, they'll never put the whims of one high-performing employee over the culture of the company as a whole. If that employee is rational, he'll quit and take his work directly to the market. This creates a fresh stream of new startups, each of which either has to be bought back for their true market value, or else becomes the new hot company that hires the masses and hemorrhages its high performers.

If not, it doesn't matter what the facts are from management's POV, it will lead to the same effect on trust & morale. Most people believe they are high performers and the work that they do for the company is valuable; if they didn't, they probably wouldn't do that work. If you have a workforce who believes they are all solid performers and then they have to confront the fact that management believes one of them is 10x better, you've got a recipe for a toxic culture.

That's a major part of why I consider open salaries to be a terrible idea for top performers. Performance and popularity are frequently uncorrelated, and I'm not talking about the asshole genius trope. You don't want to force your best performers into allocating lots of time schmoozing to ensure everyone loves them and isn't offended by their higher pay.

Almost nobody thinks they're below average in performance, but mathematically some people have to make less than average.

I've always heard this is the Netflix model.

> difference between developer salaries at any company varies by maybe 50%, whereas the productivity varies by at least a full order of magnitude.

I like your thought process but do you really believe this is possible? There are few fields where you can observe order of magnitude differences in salary. As you said, human nature seems to reject this, likely because it does not really occur in the wild. Even in sports it is rare for a particular position to have pay disparity to that degree.

What's obvious about that? I can pretty well guarantee the existence of golfers who need 10x the strokes of professional golfers. I can definitely guarantee the existence of people who can't manage 10% of the running speed of a gold medal sprinter.

The 10x programmer idea also applies to adults working as programmers. If you were to limit the runners to an analogous population (runners, I guess, or even healthy adults), I'd definitely take that bet.

[0] His peak speed was a bit faster (~27 mph), but the point stands...

Most people could beat a par 3 in less than 30 strokes given 1 week of exposure to golf.

> I've always heard this is the Netflix model.

Also, Valve. By some accounts, this creates terrible working environment, where people are competing instead of cooperating. Not to mention it distorts the incentives, as devs are heavily incentivised to project an image of being impactful high-achiever (as oposed to actually just being one, and not having to manage one's image). Of course, it also happens in regular companies, but here higher stakes make the game more vicious.

In many organizations, quadrupling the number of people that report to you is worth doubling the delivery time, hands down. Number of reports is an easy measure of influence.

The outcome isn't higher quality or better work, just capture of perceived value. The super productive developer has a risk/reward ratio. When you get a little older, stability has a value of its own.

In a team environment that is not so easy.

Is it the code, the communication, the business sense, building a good team? Who made that million? And who only made 10 bucks?

On the other hand, this seems like a fundamental management failure. The identity of the star performers has not been a mystery to the actual engineers working on every team I've ever been a part of. The information is not unknowable. Also, we already have a pay grade of "10 bucks": Some people get fired.

Your idea works in teams where everyone at all levels is switched on and tuned in.

I've got many many years experience, can solve any challenge, and work at twice the rate of most of the developers I have worked w/ in the tech stacks I focus on(ruby, elixir, reactjs/javascript/ember/angular etc)..

So I decided to go at it on my own and charge a rate I felt I was worth. Best career decision I've made so far. I think every developer reaches a point where the only way they can make more is to move into management and stop being a developer, or branch out on their own. I myself hate being a manager and love being a developer.

Managers generally seem to think that a developer is a developer is a developer. When there is a clear difference between a $50/hr developer and someone who can charge $250/hr in the time it takes to solve the same problem. What takes a $250/hr dev 1hr to solve correctly, might take a jr dev 5hrs to just "get it working."

I think this, above all else, is the key to the frustration and ever decreasing salaries we're seeing. The market has spoken: employees just aren't worth that much. If you want to capture more of the value you create you'll need to go into business for yourself. It's risky, but sitting a desk in a huge office watching rates go down and down will probably turn out to be more risky in the end if you can't retire before it gets too bad.

Having said all that, would you mind expanding on exactly what you did?

I was complaining one day about having WAY to many clients. He said and I'll never forget it, "if you have to much work to do, you're not charging enough."

I started 2.5 years ago at $70/hr and am now at $135/hr after several rounds of raising rates. Sometimes I would lose a client when raising my rates, but that was ok and really was the goal. They were usually the most painful to deal w/ anyway. My best clients usually never even balked at it. Just said ok and kept on paying.

I then got to the point where I needed to give myself a brand and bring on another developer because I started taking on very large green field projects(this was something my lawyer and accountants suggested for insurance/legal/protection reasons).

At that point I got more advanced and started doing some content marketing, facebook ads, and google ads to keep the pipeline running. The hardest part was keeping clients lined up in the beginning. Because I would get a client, work the client and during that time stop looking for new clients. Which lead to a lot of down cycles with no work to be done while I looked for the next client. This is still an ongoing thing we're working on at this time to improve our client acquisition techniques.

I also use a pretty unique billing structure that my clients seem to really love. You can read all about how and why we chose to do it this way here https://blog.grillwork.io/why-we-no-longer-use-fixed-price-c...

My partner and I now do about 20-30hrs a week for clients pretty steady and spend the rest of the time working on projects we own fully that we hope can generate recurring revenue. It has been a really fantastic journey that I hope never ends.

Every day get really inspired by the stories on indiehackers.com and just find this way of work extremely fascinating. Very rewarding both personally and financially so far and I don't think I'll ever stop doing what I'm doing if I have anything to say about it.

On top of that, your unicorns are only really worth their wages if they are solving problems no one else can or if they are mentoring others.

With the right unicorn, one can act swiftly, groom a lean architecture, and make instinctive calls that move the needle of the entire roadmap. Real unicorns present sound technical strategies and inspire new opportunities that help push the company to the next level.

As a developer, what I want is kind of the opposite. I don't want to be paid more than others if I'm more productive, I want to work fewer hours. Pay me for the value of my work, not how long it took to do it.

Attempting to build a "quantity over quality" organization is bad for the reasons you list, but "all quality, no quantity" is a close second in being detrimental.

Each critical "4x" employee that you have is only beneficial if they stay at your company. Burning them out because a company is ruthlessly focused on keeping their staffing lean by only hiring "4x unicorn-ninja-guru-rockstar" developers is a quick way to trigger management to swing the pendulum too far in the opposite direction.

Edit: fixed a typo

I'm not advocating employing talentless monkeys, they still need to be good at what they do but from a business perspective it's a more complex and wider ranging decision.

I think it is more like 90% of time the person invests and 10% performance bonus. That way the one with to 50% higher salary would probably be 5 times as performant as the average dev. If that is fair, is a different (and very difficult) question.

https://jobs.netflix.com/culture/#introduction

There is a chance of the four who are not as capable today, 1-2 might become a stars in the future. He/she will be more loyal because of the opportunity the manager gave them.

Hiring for such micro optimization is inefficient at best, ineffective usually, and counterproductive at worst.

The existence of a 10x developer is a question of what you use as a reference point for your scale.

I think we need to put the myth of the 10x developer to bed. 99% of the time, the 10x guy is just someone who solved the same or similar problem at his or her last job and are simply exercising their experience. Sure there are outliers, but that's the same in every field - whereas in programming 50% of people believe that they're the 10x guy and that all their cow-orkers are slothful idiots.

If you want to talk about it from a financial perspective, talk about the rate of return.

Can one developer do ten times the work any other developer does during a week? Probably not.

Can one developer have a rate of return such that they get ten times more valuable work done? Almost certainly.

So developer A delivers 3% improvement per year and developer B delivers 6% improvement per year. Across a career, if you start with 100 units, developer A delivers 245 units at the end, and developer B delivers 2008 units.

Some tough problems that took other skilled developers months they could solve in a couple of days and they could consistently do it across the tech and domain sphere.

I think the issue is people claim to be 10x, if you're claiming to be 10x then most likely you are not, the 10xers I've met have all been very humble.