Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

151–160 of 543 posts

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

#151

Earlier quoted context omitted.

I don't think it "attracted" a certain kind of people, I think the people who were already in tech just became more wealthy and powerful, and that, predictably, brought out the worst in some. The worst qualities of "tech" people can be conflated but I think have a different flavor than the worst qualities of "finance" people. It's really just the same obnoxious behavior you can spot in young tech people. Some people…

No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is [software engineering vs business development] and how to approach it [optimal solution vs soonest deliverable]. You can also trace personal backgrounds and you'll see a much higher representation in the…

Speaking as an old school basement nerd (coding since middle school, 90’s): If I can do cool things with code _and_ get paid, I’m gonna go do that. Business constraints make it feel much more interesting than writing code in a vacuum.

Also money is nice.

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

#152

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…

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.

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

#154

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…

> Nearly all complex technical projects are owned by one super smart person (Ex: linux).

strange example, considering that the super-smart owner is purely a delegator at this point, and there are thousands of contributors.

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

#155

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

My university has an alternative entrepreneurial focused “senior design” course open to engineers and cs students. Because of scale the CS students are now separated in a different section. All I can say is the level of toxicity that I’ve witnessed from cs students to engineering students has made this a much nicer course to work with teams.

Engineering students can be ego driven now it alls sure, but the level of toxicity behavior and assumptions of superiority I’ve seen from CS students makes me glad I don’t have to deal with them anymore.

The primary fault I see, and it’s buried in the abstractions comments from others is the assumption that their knowledge is all encompassing because it is so abstracted. The inability to attach it to contextual realities is taken as virtue rather than a risk factor.

I always go back to the fast company article on the coding team behind the space shuttle and their culture. The difference is telling in terms of qyality and risk tradeoff. Realistically the number of engineers who will design something that could kill someone and software developers who will exist at opposite ends of the percentage scale. That reality manifests in professional culture. We’ve seen it in so many places.

This threat is insightful but not in the way commenters likely think.

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

#156

> "Engineers don’t own software, teams own software" This is often the opposite of the truth. That is, teams are much more often formally-owning software, but "owning" in the sense of actually being responsible and feeling responsible for its functioning, well-being, and strive towards polish and realization of potential - more often than not, it's one or a few individuals. If it's a large software system, a lot of p…

I agree with you, but in a different directions. Often the software is owned by the company, who are just renting the engineer's labor.

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

#157

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

No, I’m optimizing for making customers happy. I dgaf about your ability to leetcode. I strongly care about the rate and quality of the things you ship to prod. This is what a 10x engineer does 10x of.

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

#158
> But someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are average (or below average). I know a lot of world-class engineers, but I’ve never met anyone who is 10 times better than everyone else across the board, in every situation.

And this is why some people fear AI

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

#159

This stuff is that self-indulgent pablum that comes from the genre of "poor are happier than rich" and such. It's always reinforced by the mediocre because everyone wants to believe they're key to something. The long and short of it is that the people who are buying your work are adequate determiners of how key you are.

> The long and short of it is that the people who are buying your work are adequate determiners of how key you are.

If that was the case then people wouldn’t need to engage in political games the way they do.

One of the traits of this work is that it is almost impossible to measure.

Post reply on HN