>everyone else is so incompetent because he doesn't try and still looks good

I'd argue against the "talent lottery" idea. Over the last 10 years as a software dev I'd argue that the 10x "rockstar" dev certainly exists, but it's almost always a case of situation/environment matching an already-moderately-talented employee extremely well.

I've seen a lot of slackers suddenly explode into a powerhouse when given the right conditions. "The grind" is very rarely the right conditions.

Yeah I've been anywhere from like 0.5x to 10x in my career. Guess what changed? Sure wasn't my IQ or work ethic.

Generally, the "10x devs" are the ones who got to do the initial greenfield work. They are the ones who understand the system, including all the undocumented domain knowledge that has been embedded into it over the years.

Ironically this actually rewards incompetence at times. If you do that greenfield work, and make a perfect system that is easy to comprehend and maintain, you will not have an advantage and will not be a "10x" engineer. You have to make the system work, and make the bosses happy long enough to earn their trust... but don't make it too easy for anybody else to come onto your team and be productive.

Of course, this incompetence is also created by management sometimes. Let's say you are a very competent dev who has the desire and talent to make a nice greenfield system that is easy to scale and maintain. Well, management will surely make sure this does not happen 90% of the time because of changing requirements and unrealistic deadlines.

>Generally, the "10x devs" are the ones who got to do the initial greenfield work. They are the ones who understand the system, including all the undocumented domain knowledge that has been embedded into it over the years.

I think this is exactly right. Especially when working on large projects with complex business logic.

I've seen one "10x" developer in my career. The way he worked was basically to leave a massive wake of data corruption, technical debt and bugs that other people would spend months fixing. Management will never notice, because everyone just accepts these things as part of doing business, and doesn't ask any questions about where it comes from or whether it was the right tradeoff. The tech debt itself doesn't bother me that much, but it always bothered me that he never took any responsibility for creating or fixing it.

However, the idea that there's a strong correlation between productivity and salary is totally a myth IMO. Getting a strong salary is all about being pretty competent, and being able to pass an interview. Once you're in to a high-paying company, mediocre competence (or slightly more) is all you really need. Me and the guy I mentioned had the same pay and the same job title, he was just having a bit more fun.

    I've seen one "10x" developer in my career. The way he 
    worked was basically to leave a massive wake of data 
    corruption, technical debt and bugs that other people 
    would spend months fixing. 

Amen. I've known one real "10x" developer in several decades. He was truly something of a savant.

I also worked with another alleged 10x developer. He was quite good, but was also given the bulk of the greenfield work and left a massive trail of technical debt in his wake.

    Management will never notice, because everyone just accepts 
    these things as part of doing business, and doesn't ask any   
    questions about where it comes from or whether it was the right 
    tradeoff. The tech debt itself doesn't bother me that much

The tech debt absolutely bothers me. It is so destructive to productivity and morale.

We had mountains of technical debt in an overstuffed monolith app. Our test suite alone took close to an hour to run and was flaky.

Management was openly hostile and derisive about attempts to address this debt. They were not engineers so it was like a laughing matter to them. "You want to have a portion of the team focus on something other than SHIPPING? Are you mad?"

Idiots. Some of the smartest idiots in the world, but idiots.

I've also worked with only one truly "10x" developer and dozens of "10x through technical debt" ones. I've very often had to finalize the famous "last 20%" of their projects which is a fun place to be in. "I thought it was almost done?"

There was one guy who worked extremely hard and extremely thoughtfully who was a master at low-level and high-level languages. Kind of a John Carmack type. But these people are like unicorns who you meet once in a career.

     I've very often had to finalize the famous "last 20%" 
     of their projects which is a fun place to be in. 
     "I thought it was almost done?"

Yeah, and then management thinks you are a mere 0.1x or 1x or 0.01x or whatever because you're moving so much more slowly than the "10x" person.

In a fair world (or a fair workplace) I wouldn't mind doing that kind of work. Ideally, I'd say "I'm willing to do whatever it takes to ship good code! Hell, I'll mop the floors or go fetch sandwiches if that's what the team needs at that moment!"

But at this point, I really try to avoid it. Unless your manager is attentive and technically savvy enough to recognize the hell you're wading through, it's basically just career suicide. The 10x person gets farther and farther ahead of you. At the end of the month he's got 100 commits and has shipped 5 features and 9 fixes. Meanwhile, you've done some fraction of that.

When I have junior devs tackle a mess like that, I make sure to put extra effort into recognizing the difficult work they are doing in cleaning up somebody else's mess. I make no claims of being a good senior dev or a good manager or anything like that. But I try to do that one thing right at least.

I think 10x engineers do not actually exist, but maybe 0.1x engineers do, and when a 1x engineer is in such an environment they may seem like 10x by comparison.

I think both 0.1x engineers and 10x engineers exist.

0.1x engineer: one of my friends works at a certain government contractor. One of her coworkers had difficulty understanding short circuiting in evaluating boolean statements, everything he writes she needs to fix, he thinks XML is a programming language, and it's just a huge mess amongst a huge list of other complaints.

10x engineer: Actually, he's still in undergrad. I was his TA for a VR class and he made a pretty great clone of Beat Saber before it was released just from watching the trailer, and in under a week. He's never heard of Leetcode, yet is absolutely comfortable with interview questions (well, I decided he didn't need practice after asking a few questions...). He's had an internship at a FAANG and finished his project early and got bored. I introduced him to a few of my other friends in the industry and they are intimidated by him too. He's this rare combination where he has the theoretical knowledge of CS, but also excels at actual engineering work.

Both 0.1x engineers and 10x engineers just feel like they re on a "different level". I don't know how else to describe it .

As for whether or not looking for 10x engineers is practical, I don't think it is.

1) It took me way too long to confirm that feeling (i.e. I imagine interview questions alone aren't enough; you have to see the engineer working).

2) I imagine most companies don't even need a 10x engineer to build the product they need.

3) They're too rare. How do I know? Because (a) none of my friends have felt that before meeting him and (b)the whole industry is still debating on whether 10x engineers exist.

> 2) I imagine most companies don't even need a 10x engineer to build the product they need.

So true. 99% of businesses are CRUD and "complex-because-of-humans" business logic very rarely needs someone like Michael Abrash as a chief scientist to get the job done.

They do. However, they can do 10X work only in deep work env, I.e. private office, no email, no meeting, etc.

Once you put the 10X eng in regular work settings, he will quickly become 1X or 0.1X

There are different ways of making teams more productive than doing just technical work.

For my own anecdote, I often can fix a lot of bugs/feature requests that come by in < 10 minutes, and often will. As soon as it is revealed that another dev will start contributing who has no prior experience, I stop most of that work and let that person take on some of those tasks & do the leftover ones. Mentorship/growing developer capabilities expands capabilities long term, even if the dev ends up moving to another project.

I also spend the most time in meetings of any IC on my team - reducing how many ICs are in meetings frees up their time to learn and grow.

I often float ideas to people for approaches to problems and designing apps/systems/features - I’ll also let others do the same. However, I also often take a light touch and leave ultimate decision making to others so they can gain that experience even if I disagree. Letting others take ownership improves the team’s capabilities.

There are many ways to expand productivity of those around you that even those who aren’t as technically gifted can do. Leadership is a very underrated part of being an engineer IMO. I do all these things as a mid-level engineer in title, but gained massive respect from management & senior ICs where they come to me for advice/ideas. I don’t fall into the trap of jealousy that others are getting credit/hampering my ability to get promoted because my work speaks for itself & I celebrate when others do well - I have no reason to feel insecure, and so help unlock my team’s productivity by removing that ego in my actions.

I'm a believer in everything you just said!

It takes a very healthy work environment (and attentive management) for this kind of work to be noticed and rewarded. Unfortunately it's not often the case.

I have tried to take this approach many times and a lot of companies/managers absolutely do not value it.

Broadly speaking, it only works if management is really involved in the day-to-day (more like hour to hour, really) process of what you're doing. Then it is easy for them to see that you are lifting up those around you and elevating the team as a whole. Without this involvement, a "mentor" and "leader" winds up looking simply like "a guy who doesn't ship enough" to management.

At my last job, management was very... absentee. There was a shortage of management and this was a bottleneck. They relied on metrics too heavily (stories shipped, etc) and didn't understand the actual processes... who was mentoring and elevating others, and who was "highly productive" but was also leaving an absolute trail of technical debt in their wake.

I feel your pain there, definitely experienced it at most prior companies. Unfortunately good engineering management is uncommon in our industry :( .

It's a shame when management fails at understanding this aspect of the game because I feel like it's one of the simplest ones to understand.

Appeasing clients? Balancing profit/loss? Juggling fire-fighting and feature-shipping? Recruiting? Hiring?

Hard, hard, hard, hard, hard.

Listening to your developers, who generally just want to be productive and generally know more than anybody else about how they can be productive? (If not, why did you hire them, if they don't know how best to do their jobs?) Understanding that technical debt exists and exerts a massive drain on future productivity?

I feel like those are the easy parts of the job.

Of course, the onus is on developers to communicate these things well. Otherwise we can't blame management for not understanding them. But I have never seen process break down because developers weren't talking. It always seems to fail because management isn't listening.

EXACTLY. Nailed exactly. Strong individual performance, ime, is a product of the right conditions allowing me to do my best.

Slacking is also a matter of motivation or the lack of it essentially, whether the "slacking" is a conscious act or not.

A "universal" 10x developer would be fairly rare to mythic even if restricted to a single complete subdomain like say Backend or Embedded development.

Well unless you had a massive skill discrepancy like say a team of a class of middle schoolers and a 10 year veteran software engineer but that would be a pedantic edge case like comparing the foot speed of a centarian and Usain Bolt. Technically a valid measurement of range but not generally useful.

> I've seen a lot of slackers suddenly explode into a powerhouse when given the right conditions

They must have had a powerhouse manager