Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

171–180 of 543 posts

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

#171
post #110

Earlier quoted context omitted.

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

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

#172

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…

It absolutely attracted different people. The inflows are much larger and not the same. For example EE used to be prestige and CS was the backup. And that would never compare to finance or law.

Yes but imo this change happened no later than late 90s. I distinctly remember how suddenly it became cool to be a programmer and the 'new type' was already making changes by early '00s. And yes, the $s attracted smart people who did not embody the old hacker ethos.

These are the new bloods that gifted us with surveillance tech, btw.

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

#173
post #51

Earlier quoted context omitted.

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral fo…

You can hide ANYTHING with financial engineering. Like off-books liabilities, systemic risk ... anything.

This comment is weird, but typical of HN. Most of the off-balance-sheet shenanigans of pre-2008 world are gone. There is now a global regulator that covers all systemically important financial institutions, that also includes very large insurers. The world of financial engineering is much lower risk and higher transparency than pre-2008.

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

#174

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…

Diversity tends to work best when there's alignment to a common goal, and diversity is adding perspectives on how to get there. Consider creating a product that will be used by people from different cultures or backgrounds. But when there's significant difference of opinion about the directional goal, as is often the case with political/ideological differences, then that diversity can be adding friction rather than insight.

Republicans will never be good at leading the EPA, basically.

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

#175

>"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." I don't think decent skills and ordinary expertise gets you that, especially "move fast" on…

Imagine there was a team that can take ordinary levels of talent and produce extraordinary results. If it could exist, this would be a great engineering organization, no?

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

#176
post #51

Earlier quoted context omitted.

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral fo…

"All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions." Trying to diminish engineering disciplines that have existed for millennia by imposing an arbitrary constraint of "3 euclidean" is pretty wank. Let's drop silly constraints. Do you have any idea how complicated concrete is? It's just sand, aggregate, cement and water. Exothermic reaction. Job done. Let's…

Not sure where you're getting that from my post.

The point is that all other engineering disciplines don't have enough design space to make a true mess of their projects. Software by comparison hasn't been limited in its design space since the first super computers started having gigabytes of ram memory in the late 1980s.

That doesn't mean that either discipline is better or worse, it means they are different. Other than math there is no other field which has as much freedom when it comes to basic design choices as software engineering, and math proofs are even more of a mess than software programs, to the point that pretty much every non-formally verified proof is wrong in some way.

Or to put another way: would railways be more or less complex if we allowed them to be embedded in a higher dimensional space instead of being essentially a 2d network on the earth surface? If you don't think so I'd like you to think about what a train schedule would look like on hyper graphs: https://en.wikipedia.org/wiki/Hypergraph

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

#177

Earlier quoted context omitted.

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…

This post is so weird on so many levels. I'll focus on this part: > You can also trace personal backgrounds and you'll see a much higher representation in the newer cohort coming from upper middle class backgrounds with families in careers like finance, consulting, medicine/dentistry whereas more in the older cohort came from more modest middle class backgrounds in engineering, academia, or even working class trades.…

It is telling that you considered their post to be about class warfare rather than different values.

The original focus of this thread was on technical precision vs. market efficiency, and how quality was sacrificed for faster conversion to sales.

That shift compromises products for everyone by creating a race to the bottom toward the minimum viable product and safety standards. When the consequences eventually hit, the aggregate responsibility and emergent effects lose direct attribution...but they exist all the same.

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

#178
post #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.

Yeah, the OP is utterly delusional. Linus himself has said that he spends most of his day merging patches. Each subsystem, example: file system or USB, has multiple highly skilled owners/gate-keepers. I am sure that the file system gurus know far more about it than Linus does, and I say that with no disrespect to Linus.

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

#179

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 people have taken from these studies is that "more diversity is better".

But she said if you actually go and read the studies, its far more complex than that. She said the data actually shows:

- A diversity of backgrounds makes a team more effective.

- A diversity of values makes a team less effective.

It makes sense. Imagine your company sells breakfast cereal. You will be more effective if you have people from a lot of backgrounds because they will understand issues your customers will face. If everyone on your team is wealthy, you might price your product too high. If everyone on your team is poor, you might never consider having a premium version of your product for wealthy areas. If your team only speaks English, you might accidentally give your product a name that plays really badly for Spanish speakers or something. And so on. These mistakes can be avoided by having a team with diverse backgrounds.

But if your team members have different values, they won't get along and your team will become less effective. Say, some people on your team want to make a product thats good for the environment. And other people on the team just want to maximise profit. Then they'll spend their energy fighting about that, and the result is a low performing team, making a confused product thats probably expensive and bad for the environment at the same time. Or, one person on the team wants everyone to like each other and someone else on the team loves competition. They'll inevitably clash. The conflict might result in personal growth - but it'll probably be bad for the team's KPIs this quarter.

In essence, nobody talks about diversity of values because nobody wants it. Ironically, not even DEI proponents.

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

#180

Earlier quoted context omitted.

Taking pride in your craft would mean having enough self-respect to both not burn your soul out for the sake of a corporation that wants to make you redundant and using it in a direction that directly benefits you. I've been in the industry long enough now to see those 10x engineers having pride in their work get their mindset shattered because John from financials thinks they can juice the next quarter by laying the…

Exactly, I'm not saying do the bare minimum I mean more that the optimal amount of work to put in is still above average but way below 10x

[deleted]
Post reply on HN