[swatcoder]

There's truth to what you're saying, but just as in sports teams, you ultimately need a certain number of players to play the game and exceptional people characteristically have an ego that only allows so many of them in the locker room. If you have too many, they get starved for the individual recognition and validation they're used to receiving, leading to crises and clashes and quittings.

Unless your project's scale is reasonably small and focused -- representing the equivalent of a true solo or duo sport like tennis -- you need committed, professional "normal" team members to flesh out the team or you'll just never have enough resources to get done everything that needs to get done.

[0xB31B1B]

Comforting yet false assertions. Great engineers tire of working with “normal” engineers, they want to work with others who they respect. A team of only great engineers can have a completely different culture than a team of “normal engineers”. Teams of great engineers are magnets that attract others. Building a great team weirdly does not become harder over time, as your project is derisked you get access to larger and larger pools of talent. Talent concentration pays an enormous dividend and is a worthy investment. Maybe things change when you hit like Facebook/google scale, but at that point… we’ve won anyway, wouldn’t be arguing online anymore.

[hot_gril]

Even before you hit big scale, there's a lot of boring work that great engineers won't want to do. And what really makes someone a great engineer is the ability to transform a hard problem to something regular engineers can handle the rest of. So I agree that 10x engineers are real and it's often 2 out of 12, but all-star teams don't work, which is why those people often get moved to run new teams/projects instead.

[0xB31B1B]

The reason people aren't motivated to do boring work is because of a poor culture of ownership, it has nothing to do with skill or "10x" stuff. Having a team of only great people allows a much deeper culture of ownership and its much easier to get people to work on the boring stuff. Allstar teams absolutely work and are the best way to work.

[johnnyanmac]

Uhh, I think it's becsuse boring stuff is boring. If you start to do repetitive plumbing aren't much "greater" than the ones working assembly lines, no?

People who describe themselves as "great" feel such work is beneath one and know there's only so many hours on earth. Easier to pay a grunt to do that instead. And hence power dynamics are established.

That ego alone is why a team of only "great" engineers is bound to fail. You have a bunch of strong but negative polarity magnets trying to stick together. It simply won't be allowed.

[noisy_boy]

Every team doesn't need to have "great" engineers; I don't want "clever" solutions to my bog standard business application, just people to write sane, clean and maintainable code.

[0xB31B1B]

This might be a definitions issue, but my assertion is not that a "great engineer" is someone who can complete leetcode hards in 15 minutes for 8 hours in a row without stopping. My assertion is that about 1 in 5 people have 5-10x the business impact of the median software developer, and if you are recruiting or managing a team you should have the goal of having your team be entirely composed of these top quintile folks. The article specifically says that you should not have this goal, and I extremely strongly disagree with that assertion in the article.

[alienthrowaway]

Some years ago, Google published a paper whose conclusion was that high-trust teams were the most productive - not the ones with the 10x developers. This obsession with the "great man" theory as applies to software is harmful to software engineering.

[johnnyanmac]

Computers are all about synergy and understanding the hardware you're working with. No one algorithm will work optimally on every chip. One of the harder problems is in. Fact getting optimal hardware use by coordinating multiple threads, chips, or entire clusters to work on the same problem together.

It's a shame some can't apply such metaphors tk humans and think "no, sure, there are single processors thst outperform entire distributed networks" we're different".

[jjk166]

You don't need a former fighter jet pilot to fly an airliner, but a former fighter jet pilot would probably do a very good job flying an airliner.

The guy who can roll his own probably also has a better idea than most what easy off the shelf solutions are out there.

[interludead]

A great engineer isn't the one writing the most "brilliant" code; it's the one who understands the problem, picks the simplest solution that works, and makes life easier for the next person who touches it.

[tremon]

In my experience, the person you're describing is hardly ever the one perceived as having "5-10x business impact". Specifically, "making life easier for the next person who touches it" is unproductive use of company time.

Which is why I have learned to stay away from people who use that metric.

[redserk]

Yeah, “business impact” is measured entirely on a short-term basis.

In 3-4 years when you need to make a drastic change, that’s when the actual business impact comes into play, but this is never measured.

In my experience with some groups, waiting another 2-3 months to do things correctly would have saved years in future work.

[thi2]

> Comforting yet false assertions. Great engineers tire of working with “normal” engineers, they want to work with others who they respect

What a great environment to train juniors. Does not sound toxic at all.

[Seb-C]

There are great and normal juniors as well.

Junior does not mean incompetent, it means unexperienced.

[systemf_omega]

Wanting to work with ambitious people that match your level is not toxic.

[BigJono]

No, what's toxic is building an environment like 99% of companies where juniors are told that everybody is the same and there's no point doing anything other than copy pasting whatever dogshit the "senior" next to them is typing into VSCode.