Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

111–120 of 543 posts

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

#111
post #20

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…

>These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. Didn't we pass the rubicon on that in the early 2010s? I personally don't feel that its "like" finance but that its the exact same behaviors from the exact same set of people. Once tech stopped being a bunch of nerds in a basement and started being a source of wealth and power, it…

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 grow out of it, and some people earn a ton of money and so have no reason to grow out of anything (not that you can't make money AND grow out of it, but there's less outside pressure to do so).

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

#112

When did IEEE become host to clickbait nonsense? This whole take feels like an editorial by a junior engineer going off vibes. It's all off-base, from the misunderstanding of how to measure productivity, to what output matters, to the idea that there is such a thing as a "normal" software engineer. It's kind of embarrassing.

It's IEEE Spectrum; it's certainly been subpar for a few years.

It seemed more interesting a decade ago, but I can't be sure if it's because the quality was higher or if was because I didn't know better…

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

#113

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…

[dead]

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

#114

Earlier quoted context omitted.

Imagine taking pride in your craft rather than doing only the bare minimum to pad your ego, what a crazy approach!

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

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

#115
post #51

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…

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…

> Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious

Eh, you can also create a bijection between all programs and the natural numbers, so I don't think this analogy gives much insight. It's also silly to think that structural engineers or whatever only have to worry about where to place indistinguishable cubes in 3d space at a single moment in time and move on to the next job.

This honestly comes off as the kind of masturbatory rhetoric the GP seemed to be talking about.

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

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

The methodology is unconstrained as another way to put it. Which, indeed, is different from engineering where constraints are non-negotiable, and thus the methodology as well. I think a lot of people doing functional programming, as an example, enjoy the constraints and the discipline that it imbues on their craft.

> engineering where constraints are non-negotiable

except that's not really true. The big difference is that to negotiating the constraints when it comes to (physical) engineering, one of the biggest factors is money (and lots of it). "Well, we could double the span but for that you'll need to have parts A1, D5 and T3 built out of ..."

Software development isn't free, but it doesn't typically incur doubling of costs for tweaks to the feature list (and I do mean tweaks).

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

#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 players hire C players etc. Building a team from the ground up is very much an iterative process of fighting complacency and mediocrity all day every day, and this guys pitch is just "give in, its not so bad".

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

#118

Earlier quoted context omitted.

Imagine taking pride in your craft rather than doing only the bare minimum to pad your ego, what a crazy approach!

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…

A lot of commenters seem not to work with very skilled individuals.

One (engineer-turned) manager I have in mind: show up at 10am, leave at 4pm, solve a zillion hard problems in the mean time. Are they 10x? If they save me 2 weeks of work with their insight then I guess I have to admit yes.

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

#119

Earlier quoted context omitted.

There is a discipline, it's just very fast-growing. Many techniques remain and become classics, it just takes awhile to realize what is fad vs classical.

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

Not very long at all ago, people waged war over dynamic vs lexical function scoping.

These days you are hard pressed to find a language that uses dynamic scoping as the default.

The needle likes to swing back and forth between dynamic be static typing but we definitely seem to be coming back to static typing again

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

#120

Earlier quoted context omitted.

The methodology is unconstrained as another way to put it. Which, indeed, is different from engineering where constraints are non-negotiable, and thus the methodology as well. I think a lot of people doing functional programming, as an example, enjoy the constraints and the discipline that it imbues on their craft.

> engineering where constraints are non-negotiable except that's not really true. The big difference is that to negotiating the constraints when it comes to (physical) engineering, one of the biggest factors is money (and lots of it). "Well, we could double the span but for that you'll need to have parts A1, D5 and T3 built out of ..." Software development isn't free, but it doesn't typically incur doubling of costs…

Maybe the real difference is that costs are hidden in software engineering, but more obvious in other disciplines?
Post reply on HN