I think "engineer" isn't really the correct word to use for the artisans who build much of the tooling used by most companies.
An engineer either wears a striped hat and drives a train, or, went to a credentialed school and passed a bunch of test and is allowed to sign documents that state "this thing, if built this way, won't collapse and kill people."
It is expected that an engineer can predict with reasonable accuracy the expense and timeline of a project, and how to maintain the resulting thing, without resorting to voodoo like "scrum velocity." In large part that's because engineers stick to doing things that are well understood and predictable, and if there's risk they resolve the risk before undertaking the project. (Is there bedrock over here upon which to build a foundation? I don't know; let's find out first!). Sure, there are engineering disasters even today -- buildings that unexpectedly lean over and door/wall things that unexpectedly fly off the side of airplanes, but those are typically organizational / process problems not "engineering doesn't work" problems.
“engineers stick to doing things that are well understood and predictable”
I’m calling BS on this. If this were true, we’d still be a ground species. Engineering has been and will always be about creating something electrical, mechanical, computerized, or all, that solves a problem. Understood or not. Engineers are not oracles. They can not predict whether a tower built in Italy will eventually begin to lean due to erosion. They can not predict that a steel beam rated for 300T of force would break at 180T. They can not predict a rogue developer removing a package from underneath their dependency tree.
You can give estimates all you want but you are still guessing.
If engineers were as you say they are, we would never have delays, we would never have traffic jams, we would never have crap software, we would never have flight.
“Engineering is the art of modelling materials we do not wholly understand, into shapes we cannot precisely analyse so as to withstand forces we cannot properly assess, in such a way that the public has no reason to suspect the extent of our ignorance.”
- Dr. AR Dykes
Engineers manage risk and cost. They certainly make mistakes, like those couple buildings that are famously leaning over in SF and NYC, or the citycorp center where they got the wind sheer loads wrong and had to hot patch the building.
But looking at the malarkey that goes on in "software engineering" or whatever -- clearly not engineering, at least not where I've seen it.
Engineering: a process of repeatably solving an understood problem predictably.
Craft: a process of solving an understood problem.
Science: a process of solving a problem without an exactly understood outcome.
Art: a process of working.
These are all made-up definitions.
I'd expect a software engineer to give me a system that locally caches and verifies distribution artifacts and validates changes -- a craftsperson who gives me a tool chain that yeets goo from the internet and builds on that without validation is not, in fact, an engineer. They could be quite practiced at the art of building working systems, but they're not managing risk....
What makes software engineering special is the systems are more complex and are cheaper to test and break. You get a completely different engineering culture when you can roll back a bad change after seeing it fail during the canary push. That, and what's usually on the line is money, not life. I'd feel a lot better making a $1M mistake than making a mistake that killed someone.
> An engineer [] went to a credentialed school and passed a bunch of test and is allowed to sign documents that state "this thing, if built this way, won't collapse and kill people."
Ahhh - that old craptacular definition. You completely ignore mechanical engineers, chemical engineers, electrical & electronics engineers. Not all engineers make bridges.
Secondly, the implied cause and effect even within civil engineering is a fantasy. Signatures on documents by credentialed engineers doesn't prevent disasters as you noted: Bridges fall down, buildings burn. Read the engineering reports on civil engineering disasters, and look at the consequences for the engineers involved.
You do some handwaving about organizational/process problems, but actually that is the key to safe engineering. Organisations deliver engineering projects and they do it across jurisdictional borders using insurance and liability and with a variety of other means that work: "signatures don't prevent disasters".
Lockheed Martin's skunk-works and SpaceX are real engineering. Any good definition of engineering needs to encompass an extremely wide variety of activities.
I would like to know the psychology behind why people wish to believe credentialed signatures are so powerful? Maybe a cross between two concepts #1: "that individual engineers run the world" and #2: "that retributive punishment of individuals works as a deterrent". I think concept #1 comes from the egotist idea of most engineer-types that we are the center of everything (I need a whole article to explain the concept). I think concept #2 is related to beliefs about the value of incarceration and also punishment beliefs derived from religion (especially in the USA where prisons are not fixing problems?).
Edit: issue #3: the idea that we should make rules about what words mean. It takes a certain worldview to think words should be defined rather than evolve (or worse that words should be part of a justice system)
> Ahhh - that old craptacular definition. You completely ignore mechanical engineers, chemical engineers, electrical & electronics engineers. Not all engineers make bridges.
I suppose you've got an engineering degree in pedantic engineering? Engineers manage cost and risk. The skunk-works stuff is marginally "science" not "engineering" given the relatively large budgets and relative lack of "we know this works." Cern is similarly an enormous engineering enterprise in that it's a huge stack of "we know this works" in service of "we're not sure what this will do"
A discussion of how "software engineers" deliver projects with neither cost or risk as part of the process implies, to me, that they're not engineers.
You are the one trying to push your definition of engineering.
I provided counter-examples that show engineering encompasses a lot more than your definition.
I simply don't understand why anyone thinks writing software is somehow uniquely not "real" engineering. Somehow we are indoctrinated to believe that it isn't but all the evidence seems to show software engineering is a valid description.
I have no lack of experience watching the fuck-ups made by electronics engineers, or the fuck-ups made by mechanical engineers. You appear to want to define engineering only as certified civil engineering. And I've seen enough of their fuck-ups too, with signatures. In fact I'll ask my bridge engineer friend from uni about it! Unfortunately my bridge building grandad is dead so I can't ask him.
The vast majority of people I encounter with some "engineering" title, in software (or the related "Architect") are in fact not trained as engineers or architects, in any field.
A site reliability "engineer" or a software "engineer" is not an actual engineer just because they've got that in their title or job description. If I were to hire a "chemical engineer" position and instead hired a chemist, or a mechanic, or a rando who's cooked meth, I may end up with things working okay, or I might end up with a serious mess, even if those people I hire call themselves "engineers" (but in fact have no formal training as such).
I'm not sure to what degree credentials matter, but do credentials matter more than "not a god damned bit" ?
I'm not saying the title makes you "not an idiot" -- people gonna people -- but attention to "cost" and "risk" is (theoretically) one of the distinguishing characteristics of engineering training vs ... "mather" or "programmer" or "philosopher".
Yeah, the debasement of meaning is annoying - vice-president is one I hate. Another one that surprises me from the US is "licensed nail technician".
I have a bachelor of engineering title I can use with my name, but that is another distinct type of bullshit.
In New Zealand one relevant legal certification is CPEng which you can apply for after receiving your degree and working for a few years: https://www.engineeringnz.org/join-us/cpeng/ And apparently our government agreed in 2022 to introduce a new licensing regime for engineers doing safety-critical work.
But in an international world, how relevant are certified individuals? When I purchase a stove from a US brand and it catches fire, there needs to be other liability/retribution/corrective systems to deal with the problem. It matters little to me who signed off on the product in the US.
Can I import custom structural steel beams? How many New Zealanders have signed off on this steel construction: https://ccc.govt.nz/the-council/future-projects/major-facili... We need a new stadium because the last one broke. Unfortunately it wasn't insured due to some cockup at the city council (which I suspect had zero retribution on the people that cocked up - I wonder if they signed bits of paper?).
Over-credentialisation is a problem too - where is the right balance? The shift to everyone needing credentials is fucked. My friends (nurses, teachers) literally weep at the absolute trash they have to "learn" for their credential. I also vividly remember the crap I needed to disgorge to get my degree.
I don't know what the answer is, but I honestly believe most credentials are pointless waste and adding more credentials is not actually effective. Neither do I believe that that the anarchy of libertarian free markets are a workable answer.
An engineer either wears a striped hat and drives a train, or, went to a credentialed school and passed a bunch of test and is allowed to sign documents that state "this thing, if built this way, won't collapse and kill people."
It is expected that an engineer can predict with reasonable accuracy the expense and timeline of a project, and how to maintain the resulting thing, without resorting to voodoo like "scrum velocity." In large part that's because engineers stick to doing things that are well understood and predictable, and if there's risk they resolve the risk before undertaking the project. (Is there bedrock over here upon which to build a foundation? I don't know; let's find out first!). Sure, there are engineering disasters even today -- buildings that unexpectedly lean over and door/wall things that unexpectedly fly off the side of airplanes, but those are typically organizational / process problems not "engineering doesn't work" problems.