[bioemerl]

In the workforce - the real answer is that the 1x engineers really really aren't operating at full capacity. You assume all parties give it their all. They rarely do.

Get through college

Do what you have to in other to get the job.

Do what you have to in order to keep the job.

10x people do some very basic things. They care. They read about code. They have side projects. They improve their skills because doing so is fun.

In a company that hires "the best" and pays very well you shouldn't see a 1x 10x divide, assuming they hire well.

In those that don't, those that only want work done and don't particularly care? That's where the dichotomy presents itself.

There is nothing inherently wrong with either group. Work gets paid, you don't have to be a magical 10x engineer to be worth the salary. And there's no shame in coding as a job instead of as a hobby.

[CobrastanJorji]

"Hiring well" or hiring "the best" isn't a panacea. People change. Before I had kids, I was working hard, working late nights, and some of my work was all-consuming. After, I've definitely had periods where my main focus was on showing up to meetings and making sure I got at least pretty okay on my performance reviews, while actually focusing on, y'know, not work. If the company doesn't punish people for becoming half as productive, a lot of the folks are going to become half as productive, even if they were "the best" at some point. Especially true when morale at a company drops. Canceling projects, being assigned to boring projects (the next year will focus on Sarbanes Oxley compliance, guys!), having your company or work dragged through the news, it adds up, and people get detached.

[Karrot_Kream]

I don't think there's anything wrong being this 1x engineer. In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance.

[throwaway09223]

> In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance.

Sometimes, sure.

But often (especially later in a career) overperforming people operate a bit more like senior partners. They have jr staff / understudies to handle crank turning. They can give direction and set things on a solid path without necessarily putting in a ton of hours.

In a healthy org, this is the "architect" role. Or sometimes the "solver," or some combination thereof. I'm sure you're familiar with the adage about the guy who charges $10k to mark the problem, $1 for the time and $9,999 for knowing where to make the mark.

[raffraffraff]

If these 10x engineers really exist, they're rare. Building an engineering department with this type of employee isn't sustainable.

In 20+ years I've only worked with maybe 2 genuine examples of the good 10x engineer, and far more examples of the bad "10x engineer" who flies around quickly reimplementing patterns that they implemented at other companies, whether they're suitable or not. Once the low-hanging fruit is all gone and only the hard stuff (and hubris) remains, they leave. Usually, after getting pissy because other engineers have inherited their crap have started pushing back and questioning their design choices. I've inherited systems built by people like this and it's not pleasant.

You also better be willing to hire constantly if you want a few more 10xers in your back pocket. If hiring a regular "good engineer" is hard, then hiring one of these is harder. You need to find them, convince them to interview, present them with an interesting challenge, have a great interview process that separates wheat from the chaff. And finally, pay them a ton and don't let them burn themselves out

Oh, and admit that replacing a 10x engineer is going to be basically impossible, not just because it's hard to hire them, but because each one that leaves your takes far more experience and knowledge with them when they go (than the 1x engineer). If the 10x moniker was really accurate, it would be like losing a team of 10.

Sometimes it's better to have a reliable team of 6 engineers in at least 2 timezones who get along well, sync up once a week and have a really good lead/manager. This is sustainable, easier to hire, onboard, retain. And less detrimental if you lose one.

[badpun]

> the next year will focus on Sarbanes Oxley compliance, guys!

How is it more boring than any other kind of project you'd do in a large finance institution?

[29athrowaway]

More often than not, it's people that care about how to create abstractions that amplify their productivity.

That is only possible if they can spend some time building abstract stuff that cannot be explained to non-technical stakeholders, which is not possible with sweatshop engineering methodologies like Scrum, or when you promote the smiling bozos that completed their 5 person-minutes Agile crash course to management.

[Olreich]

Abstraction is not a panacea. It's often the root cause of significant technical debt. Abstracting as late as possible is often the best course of action, as it give you more information about how to abstract from the initial implementation.

[kodah]

Most people think it's the people that are special or underperforming, but my view is probably a bit more contrarian. I think that some environments work in such a way that only a few can succeed while others make success possible in a network effect or on more manageable scale. I don't think that environments that produce the former really mean to; rather I think it's the leaders that are unable to craft incentive systems, pool resources, or effectively communicate that end up creating these kinds of ecosystems. It's really a fundamental misunderstanding of the people part of the job, which turns out to usually be the hardest.

[mirekrusin]

I disagree. You should work on bottom up abstractions, base yourself on first principles. Amending abstractions built like this are cheap and straight forward. This is opposed to top-down, gluing already made monstrosities.

[29athrowaway]

Yes, that's why it takes effort to learn how to properly create abstractions that solve more problems than they cause.

[pksebben]

I would add to this; that a certain amount of bad abstractions are preferable to underdoing it. The learning from failure (when there's sufficient investment in the outcome) is far more valuable than avoiding inefficiency.

Learning better ways is a process - so long as you remain robust in the face of failure and grow from it.

[janstice]

Improper abstraction does usually lead to significant technical debt, but if you are lucky you can bank your short-term successes and leave the tech debt to someone else.