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”.
“Normal” engineers are the key to great teams
231–240 of 543 posts
Re: “Normal” engineers are the key to great teams
#232Re: “Normal” engineers are the key to great teams
#233Earlier 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.
Re: “Normal” engineers are the key to great teams
#234Earlier 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).
Re: “Normal” engineers are the key to great teams
#235I 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.
Re: “Normal” engineers are the key to great teams
#236I 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…
Re: “Normal” engineers are the key to great teams
#237Their 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
#238I 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…
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
#239Earlier 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.
Re: “Normal” engineers are the key to great teams
#240I 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…