> "I assumed that people who enjoy software would be into intellectual stimulation but I've learned that this is wrong."
It was truer in the 1980s-1990s, when programming was not a prestigious or high paying job and computers were much cruder and required much more skill to get adequate performance from them. Generally, aspiring hackers were very well read people.
There were, of course, corporate programmers doing business programming back then too but they weren't considered hackers and wouldn't even have wanted themselves to be considered hackers.
> "FPGAs reconfigured during program execution to speed up hot paths"
The IEEE conference on Field-Programmable Custom Computing Machines (https://www.fccm.org/) is in its 34th year, to give you an idea of how old that idea is. The answer to your question is both 1 and 2 and also 3. that FPGAs have rather poor efficiency, both in terms of cost and performance, so it's not worthwhile outside of a few niches.
Developer testing is checking whether the code does what the developer themself thinks it should. QA testing is checking whether the code does what the customers / users / rest of the world thinks it should.
The problem with that quote is that all of us reading this are telescope operators, not astronomers. The quantity and quality of our telescope photos is what we are paid for so we have no choice but to know our chosen brand of telescope inside and out.
The things you list illustrate @aplamers point that software "doesn't really kill people". If you asked the average person on the street, they might just barely remember the Boeing incidents and the rest they probably have never heard of. Even something as gruesome as the Therac-25 incident is probably unknown to most.
It's the rising tide of low-level everyday harm from software that is going to motivate the public to start coming after the software industry.
> "How many centuries did it take for civil engineering, for example, to become the codified, standardized, and respected calling it is now?"
But the software industry is not starting from centuries ago. We have the benefit of modern education and literacy rates, instantaneous global communication, centuries of experience and data in other life and safety critical fields to draw on to understand how to establish a reasonable level of safety in the face of uncertainty, vast libraries of knowledge and data that can be called upon online, and nearly a century of increasing regulation and professionalization in those fields. Sorry but that doesn't hold up to scrutiny.
Software "engineering" doesn't kill people instantly in a flashy way, sure, but it has become more like leaded gasoline, a widespread low-level harm whose effects are increasingly evident in hindsight. You pretty much can't go more than a couple of days without hearing about another massive consumer data compromise by hackers, CVE, major services outage, etc. At some point, there is going to be a software related incident that is bad enough that the public and government is going to demand accountability.
"Is the company consistently profitable or not?" and "Are revenue and profits growing over time, stable, or declining?" are very important questions to answer, particularly if stock grants are part of the compensation package.
For developers who work on products, getting a sense of whether the product of the team you'd be joining is a core part of the business versus speculative (i.e. stable vs likely to have layoffs) and how successful the product is in the marketplace (teams for products that are failing also are likely to be victims of layoffs) are also very important to understand.
Casual of research shows that the ACM's Code of Ethics can be traced back to its Guidelines for Professional Conduct in Information Processing dating back to 1966 (https://www.acm.org/code-of-ethics/1966-acm-code) and the IEEE's Code of Ethics can be traced back to a precursor organization's Code of Professional Conduct dating to 1912.
TDD is a development methodology, not a testing methodology. The main thing it does is check whether the developer implemented what they thought they should be implementing, which is not necessarily what the spec actually says to implement or what the end user expects.
Petzold's Code is a popularization aimed at non-technical readers, as you said. ECS is a textbook aimed at college-level CS and Comp. Eng. students and goes into sufficient technical depth for the reader to build their own digital computing systems.
I have both a computer engineering education and have read the book. My recollection is that it's good for what it is but omits[0] a heck of a lot of necessary background knowledge to apply the material outside of the limited context of the book. I'm not saying that it's not good, just be aware that it's not the whole picture, so to speak.
[0] or perhaps it would be better to say "has no choice but to omit" or it would be ten times thicker than it is.
Read David Tribble's "Go To Statement Considered Harmful:
A Retrospective" instead: http://david.tribble.com/text/goto.html . It contains the entire text of Dijkstra's paper and goes over its meaning in a modern context on a paragraph-by-paragraph basis. It's very well written and makes clear the "encourages spaghetti code" argument, while true at the time, applied in a era where basic control flow constructs that we now take for granted did not exist in commonly used languages.
It was truer in the 1980s-1990s, when programming was not a prestigious or high paying job and computers were much cruder and required much more skill to get adequate performance from them. Generally, aspiring hackers were very well read people.
There were, of course, corporate programmers doing business programming back then too but they weren't considered hackers and wouldn't even have wanted themselves to be considered hackers.