“Normal” engineers are the key to great teams • Hacker News Board

Re: “Normal” engineers are the key to great teams

#311

Post by matthewsinclair » Fri, Mar 14, 2025, 6:57 AM UTC

I agree wholeheartedly with this article, and wrote about the same thing back in 2018 [0]. The Hero (or 10x) Programmer is a seductive archetype and I can see why managers and leaders and teams are attracted to the idea. The simple fact is, tho, that just about anything worth doing requires more than one person these days and the toxic negative side effects of “10x disease” on a team ends up outweighing any positive productivity effects a single person can bring.

[0]: “The Myth of the Hero Programmer” https://matthewsinclair.medium.com/0061-the-myth-of-the-hero...

Re: “Normal” engineers are the key to great teams

#312

Post by xkq8zmqe9-0x » Fri, Mar 14, 2025, 6:59 AM UTC

superconduct123 wrote: post #24

I think 10x is an exaggeration but I've found its really common to have 1-2 people who do a big bulk of the work The thing I don't understand personally with these people is why they care so much about work when the rewards are not proportionate to doing so much extra work. I get it if you're a founder of a startup but not if you're at a big company Yet every big company I've worked at there are always 1-2 people on…

> why they care so much about work when the rewards are not proportionate to doing so much extra work.

Most of the >1x engineers I met can’t help themselves and be their best version.

Re: “Normal” engineers are the key to great teams

#313

Post by freddie_mercury » Fri, Mar 14, 2025, 6:59 AM UTC

WgaqPdNr7PGLGVW wrote: post #212

freddie_mercury wrote: post #132

Earlier quoted context omitted.

> The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5 Google has something 25,000 developers. You think Google has 5,000 people working on novel design spaces? That number sound way, way too high. By at least an order of magnitude. And Google at least has customer facing technology compared to the thousands of companies whose developers only work is, say,…

> You think Google has 5,000 people working on novel design spaces? Yes. Maintaining a bridge is in general not novel. There are clearly established best practices that have stood the test of time. Maintaining a ridiculous tangle of millions of lines of code is novel. There are no best practices on par with other engineering fields. We are at the stage of rough heuristics in most parts of software dev. One day there…

IBM's S/360 was millions of lines of code in the 1970s. Managing millions of lines of tangled code is not novel. It is older than most HN readers.

Re: “Normal” engineers are the key to great teams

#314

Post by Dracophoenix » Fri, Mar 14, 2025, 7:00 AM UTC

gilbetron wrote: post #192

0xB31B1B wrote: post #117

I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…

In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 1…

> but great teams makes great software, not great individuals.

For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals along with the contributions of a small number of itinerant volunteers. While teamwork can be an important if fickle instrument, it tends to be a lightning rod for inviting too many cooks into the kitchen. What is often downplayed or goes unsaid in these commendations of teamwork is the place of an individual mind as the wellspring, the sine qua non, of great ideas and projects, including software. As is often the case, one person can solve an issue that has stumped thousands of others. Such individuals tend to work at a faster pace alone than the de facto committees that teams often become as they lose their agility, foresight, and focus. Unlike a football team, coding doesn't require a minimum number of people to achieve greatness. On the contrary, the opposite appears to be true - that there's a Dunbar's number for doing good work.

Re: “Normal” engineers are the key to great teams

#315

Post by sam_lowry_ » Fri, Mar 14, 2025, 7:00 AM UTC

matthewsinclair wrote: post #311

I agree wholeheartedly with this article, and wrote about the same thing back in 2018 [0]. The Hero (or 10x) Programmer is a seductive archetype and I can see why managers and leaders and teams are attracted to the idea. The simple fact is, tho, that just about anything worth doing requires more than one person these days and the toxic negative side effects of “10x disease” on a team ends up outweighing any positive…

See also The Worst Kind of Programmer [1] which talks about how detrimental the work of high performers often is.

[1] http://mikhailian.mova.org/node/284

Re: “Normal” engineers are the key to great teams

#316

Post by fmbb » Fri, Mar 14, 2025, 7:04 AM UTC

sam_lowry_ wrote: post #315

matthewsinclair wrote: post #311

I agree wholeheartedly with this article, and wrote about the same thing back in 2018 [0]. The Hero (or 10x) Programmer is a seductive archetype and I can see why managers and leaders and teams are attracted to the idea. The simple fact is, tho, that just about anything worth doing requires more than one person these days and the toxic negative side effects of “10x disease” on a team ends up outweighing any positive…

See also The Worst Kind of Programmer [1] which talks about how detrimental the work of high performers often is. [1] http://mikhailian.mova.org/node/284

The real 10x devs are the ones that just do ten times less work than the rest but you cannot tell from their output.

Re: “Normal” engineers are the key to great teams

#317

Post by t43562 » Fri, Mar 14, 2025, 7:07 AM UTC

throw4847285 wrote: post #148

t43562 wrote: post #99

Sometimes I feel useless compared to other people - usually while I'm struggling with something and seem to be achieving nothing. This talk of xN programmers absolutely hits on all my insecurities. Then other days I solve 3 problems for other people which are easy for me because I have bashed my head against those particular kinds of walls before. I suddenly feel worthy again. I'm productive when I know exactly what…

Thanks for your candor. Your experience is extremely common. Who benefits from rhetoric about xN programmers? It's about extracting the most value out of you in an unsustainable way. It's shortsighted. If you're going to be productive while maintaining your sanity, it is an uphill battle. This is especially true for people who are especially sensitive to this kind of pressure, and can drive themselves into a wall if…

Yes, I have felt it worse with the kinds of managers who try to drive you by making you feel insecure. They're always making sneaky or not-so-sneaky comparisons.

Re: “Normal” engineers are the key to great teams

#318

Post by nextts » Fri, Mar 14, 2025, 7:13 AM UTC

roncesvalles wrote: post #269

>A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week. Agree completely, and 10X engineers build such organizations.

10x managers

Re: “Normal” engineers are the key to great teams

#319

Post by nextts » Fri, Mar 14, 2025, 7:23 AM UTC

0xB31B1B wrote: post #117

I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…

It is teams in a functional organisation. Once everyone is performing then how you organise work: how you communicate complex ideas, how you order work, how you set up each other for success matters a whole deal.

If you measure something meaningful it's teams. If it's LOC or some macho measure of productivity (rewrites in Rust using the hardest frameworks) then yeah it's those "tenexxers".

Re: “Normal” engineers are the key to great teams

#320

Post by LarsDu88 » Fri, Mar 14, 2025, 7:25 AM UTC

The 10x trope was something Steve Jobs really learned from his days at Atari.

If you look at virtually all the games programmed from 1975 to around 1995, the programming "teams" were incredibly small. Until the Sony Playstation came out, virtually every videogame was written in assembly with no source control whatsoever. Even PC games like Starcraft (released in 1998) had code review done by printing out the physical code and going over it with a marker [this was about the last time Elon Musk had a programming job cough). There was no source control and graphics APIs (if they existed at all) came in thick manuals.

For context, the credits to the Sonic the Hedgehog, a multimillion (now billion) dollar franchise, had just one "Chief Programmer" Yuji Naka, and 2 "assistant" programmers. Most of the time the assembly code would be incomprehensible to anyone but the person who wrote it. I believe there was very little actual "collaborative" programming going on. The gulf between a programmer who could merely code (which meant moving sprites around in assembly), and someone who could ship an actual game, let alone a decent one, was quite immense. When it came time to develop the first 3d Sonic game for the Sega Saturn, Yuji Naka was busy, and an American team was set to the task. Working 14-20 hour days, and forced to write a 3d game engine on Saturn hardware in assembly (due to the crappy state of C compilers at the time), this team could not ship an acceptable game in the 1 year timespan needed by the company.

I think quiet advances in tooling have made both collaborative software engineering more feasible and more effective compared to the 80s and 90s, where entire multi-million dollar industries by necessity sat on the shoulders of a handful of high skilled software engineers.