Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

231–240 of 543 posts

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

#231

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…

You’re over optimizing for engineering skill. The majority of projects don’t need a team full of A players, and trying to get that is going to limit you. Get rid of team members that make your life harder. Keep the ones that make it easier. > Individuals ship software not teams I can’t see how this is remotely true outside of contorting some definitions of “ship”.

Not needing something is different than not benefiting from something.

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

#232
totally agree a team with full of 10x engineers would just introduce new techs every month, if not they would get bored pretty fast and leave the team anyway. most of the time normal engineers are more suitable, especially during maintenance phase where there are many boring/ repetitive tasks

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

#233
post #195

Earlier quoted context omitted.

Can you give some examples of things you'd consider fads versus classical in software?

It was somewhat common in the 1970s and before for programming languages to support abbreviating variable names when you referenced them. So for example, you could say patients = 400 x = pat / 2 And x would be 200. This seems like an obvious footgun today and I don't think any language designer would even consider it, but it seemed to make sense for a while.

Were they actually supporting abbreviating or just doing something like only storing the first 3 characters of the name? That feels more like something a compiler trying to fit in 8k of RAM or whatever would do.

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

#234
post #110

Earlier quoted context omitted.

TDD. Agile.

I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).

Just to be clear, do you mean full-dogma Rails tutorial write a bunch of trivial tests before writing code TDD?

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

#235

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…

when people talk about a players I feel like a lot of times it's really just the person who knows the project best or maybe they wrote a lot of the original code so they have the best idea of how it works. My point being who's an A player in my opinion is not reflective of actual skill per se but rather other factors.

Knowledge of the domain helps a lot! But software engineering and dev tools are also domains that are transferable. I have outperformed coworkers with much more code domain familiarity because I had more engineering/debugging/tooling domain performance, or better ability to design and communicate etc etc.

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

#236

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…

I don’t think I agree with your level of cynicism, but I definitely think my biggest enemy at work is complacency. I joined a company in the last few months, and it seems like this codebase lost the war against complacency years ago, and it’s such a hard hole to climb out of

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

#237
I feel like this article completely misunderstands the point.

Their two big arguments are that 1) people aren't 10X at everything, they are at most 10X at specific things and 2) what good is a 10X engineer if they are on a team that can't perform at that level?

There isn't something magical about 10X engineers, but the fact is there are engineers who have developed the skills to greatly exceed their peers and work in those sub disciplines at which they have this skill. Who cares if your 10X mobile app engineer would be no better than anyone else at microprocessors, they aren't working on microprocessors. Likely anyone could become a 10X engineer, but most don't. It's like great athletes or great musicians - whom no one would question are 10X better than average even if quantifying skill in those domains is hard - maybe there is some level of god given talent but for the most part it's years of effort that other people just don't put in.

Then yes, engineering is often a group effort and a bad team can certainly hold someone back, but just as in sports a strong player can certainly elevate an otherwise mediocre team particularly if well utilized, a 10X engineer can massively improve the output of those around them. No one on earth would say it doesn't matter if our band had a great cellist because the rest of the orchestra probably isn't exceptional. If a team holds its high performers back, that's a problem with the team, not a limitation of high performance.

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

#238

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…

A lot of people will agree with you and a lot of people will disagree with you because the subject might as well be food and for some people that’s coleslaw and for others that’s master chef.

Both have their place. On the topic of greatness (your example, Linux, as opposed to say a build script for vending machine firmware) I couldn’t agree more with both you and the people disagreeing with you.

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

#239
post #181

Earlier quoted context omitted.

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 a…

> 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.

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

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

#240

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

I think one thing that is very different about software engineering is that it's the only form of engineering I'm aware of where a very substantial fraction of the people employed to do it lack basic fundamentals like "being able to do it". Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day. They don't have a sense of what makes sense an…

I can confirm that some (30%?) mechanical and biomedical engineers follow the described problem "solving" strategy exactly. It's not just software engineers.
Post reply on HN