Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

241–250 of 543 posts

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

#241
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…

Disagree. What makes software unique to other engineering disciplines is that it isn't a discipline at all. What makes software so great is how quick the iteration cycles are. Software sits at a higher abstraction level than physical hardware, so much of our time is spent throwing at the wall and seeing what sticks because that's often (although not always) the best use of time.

RE: Quick iteration cycles - definitely agreed.

Back in my EE days in 90's, "full stack engineer" meant, for example, being able to build a physical calculator by connecting a numerical keyboard, bunch of 7 segment displays and a micro controller using bunch of wires on a circuit board, and THEN writing the assembly code to allocate memory and run your program in an infinite loop. You had to erase your EPROM with UV and burn your program to the chip over and over every time you changed a byte in your code. Debugging? You wish.

As a side effect, full stack engineers had the risk of getting electrocuted, or going blind :)

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

#242

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…

A great quarterback with an otherwise average team is still going to beat an average quarterback with an otherwise average team every time. That a team is more than the sum of its parts just means that adding great team members can lead to more overall gain than their skill alone would imply as they boost those around them.

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

#243

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…

This is bullshit. I'm sorry you've never had the pleasure of working in a high performing team.

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

#244

Earlier quoted context omitted.

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

I say this as someone who loves software: software is not special.

Every discipline has infinite depth.

Railways in 2D may seem simple but there the simplicity may be intentional. Just like when you write software that runs things like planes, trains, or medical devices, all of a sudden you’re writing in C, without recursion, without function pointers, without using the heap, etc.

Look at the concord airplane. A mess of a project.

Look at anything in biology and human health. The complexity is unimaginable compared to software.

Edit: reduced emotions

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

#245

Earlier quoted context omitted.

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…

that's a bad analogy because a single football player cannot ever deliver a match entirely on his own. A single developer can absolutely deliver a full product on his own, it's not inherently a team sport whatsoever. You could make this claim about many things, "blacksmithing is a team sport!" Nonsense.

While a single talented developer can conceptually complete a whole project (of some kind) on their own, the concrete reality is that they're often being tasked to do so in the context of some time and resource bounded opportunity.

There's only so much code they write per unit time, only so many designs they can consider, only so many meetings they can attend, only so many demonstrations they can perform, only so many regressions they can debug, and really, only so many domains they can master.

Solo projects written by excellent engineers can be stunning works of craft. Many of us prefer to work that way, and accept the compromises of scale or time that are associated with it.

But most projects that you're familiar with need a team to produce them in a way that meets their real-world time and resource requirements. That's where the sports analogy comes in.

(And the same is true for the blacksmith and tailor. One master blacksmith or tailor might do stunning work, but they can't outfit and army or dress a court ball on their own. They need support, and that support often needs to be of a different level of mastery than themselves, if for no reason but to facilitate needed coordination and deference.)

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

#246
Fuck this constant dehumanisation and categorisation of the working class.

The key to a great team is great leadership.

Most people are terrible leaders, and they think that what they are worth is what makes them leadership material, even though they didn’t earn that worth themselves and didn’t put in a hard graft.

The key to a great team is a fucking team. Only then can there be a leader.

Let’s talk about ‘normal’ CEOs, 10x CEOs, and for that matter, ‘retarded’ CEOs, considering a particular one of them favours that insult. That’s the implication of ‘normal’ in scare quotes no?

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

#247

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…

[dead]

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

#248

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.

You don't need a former fighter jet pilot to fly an airliner, but a former fighter jet pilot would probably do a very good job flying an airliner.

The guy who can roll his own probably also has a better idea than most what easy off the shelf solutions are out there.

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

#249

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 don't think, excluding some scenarios at well-disciplined firms that anything like "engineering" exists in programming.

The processes surrounding development often strike me as haphazard, cargo-cult like behavior, and entirely subjective.

Regarding people not remembering stuff--yeah that's probably true, but there's a lot a typical developer has to jump between--do people really get to "specialize" in JUST like writing Java CRUD or something anymore?

Feel like there's always also troubleshooting some Docker thing, some cloud provider, some build system, some pipeline etc etc.

When there's no stability and moving targets, maybe you're not incentivized to be a "specialist" on a language or whatever (this might also be painting oneself into a corner for their career) given how easy information retrieval is today?

RE: the scenario

Is this real?

I've never been employed at any sort of fancy role but I've never encountered this kind of thing (publicly) involving me, and I generally get on well with others, so I assume I'd have seen it by now

I'm sure plenty of programmers pasta from LLMs constantly now, but I've never had bizarre low-hanging "what do" inquiries.

Most people have some discipline and structure when asking questions:

- I'm attempting to integrate library x into the project - I've done the following and the build fails in CI with $ERROR - I've checked x, y, z - Have you encountered something similar?

This indicates some level of actual understanding of how things work, or prerequisite research prior to asking.

Also, where can I get a job where they hire people this minimally competent? I'm seriously burnt out and this seems like a nice change of pace.

I'm totally serious with that question.

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

#250

Earlier quoted context omitted.

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.

“Call 1-800 beageek”. Remember that commercial? That was around the time software dev went mainstream, late 90s iirc.

Mainstream is different than upper middle class and ambitious.
Post reply on HN