Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

Post reply on HN
Print view View original

301–310 of 543 posts

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

#301

Post by mirekrusin »

The key to great teams is the key to great teams. Anything else is context dependent (what, who, when), nuaced, unpredictable, stochastic, often non repeatable, sometimes contradicting, changing with time (as in maturity of projects), requires adaptability, differs for different people etc.

I'm not giving up on answering the question. It's an aid for you to answer this question by yourself now from where you are.

Argument in this article feels like advice that key to writing best programs lies in writing functions with average LoC.

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

#302

Post by kookamamie »

What a bunch of nonsense. The article flattens the "10x" definition to mean quantity, where as in reality the most talented people can reach hights, qualitatively, the 1x cannot. The Infinite Monkey Theorem - no amount of 1x'ers would have produced Einstein's contributions. The same applies to software, in many ways.

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

#303

Post by 0xB31B1B »

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…

Great teams are made of great individuals. All of the policies and trust and rituals and expectations are based on the performance of the bottom quintile of the team. If the bottom quintile of the team is still the top quintile of "engineers applicable to this problem" you will have a radically different and improved culture and performance than if the bottom quintile of the team is a median engineer, and especially a bottom quintile of "engineers applicable to solving this problem".

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

#304

Post by Seb-C »

thi2 wrote: post #181
0xB31B1B wrote: post #167

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.

There are great and normal juniors as well.

Junior does not mean incompetent, it means unexperienced.

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

#305

Post by 0xB31B1B »

hot_gril wrote: post #185
0xB31B1B wrote: post #167

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…

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.

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.

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

#306

Post by mjburgess »

josephg wrote: post #179
mjburgess wrote: post #164

The author: > Charity Majors is cofounder and CTO at Honeycomb.io, a platform that helps engineering teams debug and improve their software applications. > https://charity.wtf/ Blog, latest article an apologia for DEI, "The diversity of your teams over the long run rests on your ability to build an inclusive culture and equitable policies."... "Don’t underestimate what a competitive advantage diversity can be" Hmm. W…

> Hmm. Why does no one argue for equitable balance of political views, or religions, or anything to do with ideas at all? Is anyone even measuring ideational diversity? Probably not, no. About a decade ago, I worked with a woman who had a PhD in psychometric assessment / quantitative psych. She was crazy smart. She said there have been lots of studies of high performing teams, and of course one of the conclusions peo…

My point wasn't that we should expect high performing teams to have a diversity of relevant values -- rather, that "diversity" is just a means of smuggling people of the same values in together under the guise of inclusion. In other words, its a kind of radical exclusion of those who do not prioritise this sort of diversity -- which is the vast majority of people. Looking around to see if the ethnic mix matches population statistics is bizarre to almost everyone.

This is a problem when these values become extremised in a population such that to select for them is to quite significantly narrow the plurality of values which would otherwise well-coexit. Consider, eg., religious communities living together before and after liberalism -- before = civil war, after = human rights. Classical liberalism is an ideology of values pluralism which thereby permits great diversity of ideas.

We should expect high-performing teams to have a diversity of relevant ideas (, and perhaps, ) of irrelevant values.

The concern arises when the benefit to team cohesion arises from an echo-chambre of shared values, at a great expense, of disruptive innovation and ideational diversity. And also, on my part, just honesty about what this sort of moralist is really aiming for -- to be surrounded by people who wish for a very narrow sort of values-homogeneity.

If "diversity and inclusion" were part of the pluralist fabric of liberal tolerance shared by the vast majority of people this issue wouldn't arise -- since then there could be a great actual diversity of opinon whilst values were shared. The issue is how peripherial prioritising these values is, de facto -- and hence how self-regulatingly narrow the "team" has to be.

If the chief value being pushed were "tolerance", such that we had, "tolerance, respect, effort" (, say) as the new moralist fashion -- then almost none would be excluded.

Consider what the impact of making "racism" a team value would be in these terms: how narrowing, homogenising, and the like. And yet, I suspect the number of people keen to work with "people as racist as they are" is not so different than "people as obsessed by diversity as they are".

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

#307

Post by 0xB31B1B »

noisy_boy wrote: post #197
0xB31B1B wrote: post #167

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…

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.

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.

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

#308

Post by Dracophoenix »

fsloth wrote: post #292
lovich wrote: post #266

Earlier quoted context omitted.

> I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation. And they’d probably be right! I remember the grognards giving me shit about memory management and me giving it right back by explaining that what they considered a large chunk of memory would be worth pennys next year because of Moore’s law and I wasn’t going to waste time considering some…

As a fun anecdote I think this same rationale - ”next years hardware is so much better” - is why so many desktop softwares 90’s->00’s became slow - ”meh you don’t have to care about performance, next year’s cpu is going to be so much faster anyway”. Then suddenly single threaded speedups didn’t happen anymore (and people realized even though cpu speeds had grown, it was not directly related to Moore’s law). Ofc your…

https://en.wikipedia.org/wiki/Andy_and_Bill's_law

https://en.wikipedia.org/wiki/Wirth%27s_law

And more generally,

https://en.m.wikipedia.org/wiki/Jevons_paradox

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

#309

Post by 0xB31B1B »

al_borland wrote: post #283
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 a lot of cases, some of those who carry all the water are doing it to themselves, and it hurts the team (and themselves). In the organization I work in we have an operations team to take care of day to day failure. Write a run book, set up ticketing, hand it off, good to go. I treat this work and hand off as a high priority, as it frees up my time to work on other things. The ones who are chronically busy and appe…

you are not describing someone who is "carrying water for the team". Someone who is carrying water for the team is, for instance, working on reliability improvements so that the errors or things requiring support occur with less frequency. Its not about being busy, its about having impact.

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

#310

Post by jillesvangurp »

nullpoint420 wrote: post #4

Most 10x engineers I've met are usually very creative and care deeply about the user experience and keeping code maintainable over time. Most 1x developers just care about getting the job done regardless of care or code quality, which in my experience has led to conflict.

And lets not talk about the 0.1x developers who are probably also a thing. If you get enough of those together, team productivity completely collapses. I've seen that happen.

1x is normal. Some people are less, some people are more. Normal is good and predictable. There's nothing wrong with normal. Normal people that put in a decent effort will produce results. That's a good thing. For a lot of long lived software, normal is what you want. You can't reasonably ask normal people to be more than normal. That would be abnormal. Putting in 120% of your best is not a thing. It doesn't work that way. You are doing pretty OK if you are getting 70-80% of your theoretical best. That's what normal is.

There are of course people who are a bit more capable than their average peers. This is often confused with working long hours. The ability to work longer is mostly something young, relatively healthy people are good at. But there's a difference between working longer and working smarter. You can't work 10x more than a normal person. There's only 24 hours in a day. The only logical way to get 10x more done is to work smarter. There is no other way. And some people really just are that good that they get more work done in the same amount of time. Part of that is experience, brains, and just being really efficient with their time.

An exhausted 10x developer is not a 10x developer. Because they'll be perpetually too tired to work smart. So they might be producing a lot of code but it will be the type of code that will need a lot of maintenance. A true 10x developer consistently writes less code with high impact without wearing themselves out too much. Doing that requires skill and experience. The best code is code you don't have to write. Use the right libraries, avoid reinventing wheels, make your code testable (so you don't get bogged down debugging it), don't repeat yourself, etc. If you find yourself doing the same thing over and over again, automate it. That's your job. Don't keep on doing the same thing. That would be stupid and somebody else will do something smarter eventually.

Post reply on HN