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…
“Normal” engineers are the key to great teams
111–120 of 543 posts
Re: “Normal” engineers are the key to great teams
#112When 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 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
#113I 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…
Re: “Normal” engineers are the key to great teams
#114Earlier 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…
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
#115I 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…
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
#116Earlier 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.
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
#117Re: “Normal” engineers are the key to great teams
#118Earlier 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…
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
#119Earlier 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?
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
#120Earlier 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…