[constantcrying]

I like the distinction between technician and engineering. So much of software development is just technician work and has nothing at all to do with engineering.

Unlike other countries in the US you can call yourself an engineer as a job description without any restrictions, so far too many people have taken on that job description, even if it does not make any sense.

[readingnews]

≥≥ Unlike other countries in the US you can call yourself an engineer as a job description without any restrictions, so far too many people have taken on that job description, even if it does not make any sense.

This is one of my pet peeves... in Engineering school it is beaten into you that what you build has to be correct. Correct as in, did you check the poles and zeros? Is this thing going to oscillate out of control and kill people in any breeze? Is this circuit ever going to go into a region where it will fail, probably killing people, and did you ensure you have circuitry that will prevent that? Is every floor of this building rated for the loads, winds, seismic activity, etc.

I feel like in software, there used to be a lot of focus on correctness of algorithms. In undergrad computer engineering we had to take algorithms and again in grad school. That class seemed like the one to teach you to be correct, but it was just in your algorithm design. So much of software today controls hardware that may end up controlling (insert your deadly item here: life support, airplanes, cars, trains, critical infrastructure, deadly infrastructure, etc) that it makes me wonder just how much holistic testing of the "in which ways can this software fail and kill people" has taken place.

[constantcrying]

>So much of software today controls hardware that may end up controlling (insert your deadly item here: life support, airplanes, cars, trains, critical infrastructure, deadly infrastructure, etc) that it makes me wonder just how much holistic testing of the "in which ways can this software fail and kill people" has taken place.

For aerospace software specifically, a lot. Embedded Software Developers also are often people who also are Electrical engineers and understand how to do proper engineering of a system. In aerospace you have very specific guidelines on how software is developed and tested and which tells you what you need to consider during/before/after the development process. As is common in engineering the "doing" part (e.g. writing the software) is the least relevant part.

[jauntywundrkind]

If anything this feels like an exception that proves the rule.

I'd wager 60% of software engineers work on teams where they have an existing product, add a feature, and then when done go add a new feature. A sizable % of this folks so have other teams working on other parts of the same codebase. Development is incremental, with no long-term vision, and certainly none of the hard metrics for success.

Speaking to the parent, we had a couple weeks of engineering ethics in our computer engineering undergrad. The dude railed on software for having defects, for being at a crisis point, and I threw back super hard & continue to think that most of the field has to face down enormous combinatorial complexity of inputs. And we have to work against moving target codebases where our added work is typically dwarfed by existing complexity. And unlike a bridge or a floor, there is very little opportunity to overbuild against specifications. We can't shoot for 130% of expected load (in most circumstances), it works until it doesn't.

Thankfully I feel like most mission-critical devices tend to have more limited missions, aren't so open ended, but most software development feels more like an ongoing effort to keep iterating and adding than an cross-the-finish-line effort. Every sprint should be at least one release right? How do we get such high assurances in such regular repeated development cycles?

[AlotOfReading]

Hillel Wayne wrote an excellent series of articles on whether software was "engineering" that included interviewing traditional engineers that were now in software [0]. I strongly recommend it.

For me, I sit next to EEs and MechEs all day working on safety critical systems. There are some differences in our jobs, but frankly I don't see the substantive differences that would make one or two of those non-engineering compared to the others.

[0] https://www.hillelwayne.com/post/are-we-really-engineers/

[another-dave]

And it doesn't even need to be in the "can kill people" bracket to cause serious harm cf. https://en.wikipedia.org/wiki/British_Post_Office_scandal

(Obviously the blame for this issue isn't solely on the software side)

[drewcoo]

It's also worth noting that an engineering degree does not make a person an engineer any more than a JD makes someone a lawyer or a beauty school diploma makes someone a hair stylist.

Except we allow people to call themselves engineers without having professional accreditation.

[randomdata]

> Except we allow people to call themselves engineers without having professional accreditation.

Naturally. We allow people to practice engineering without professional accreditation. It would be completely nonsensical to prevent someone from being able to state literally what they do. Some specific engineering areas (those most likely to cause human harm) may be more discriminating with respect to who is allowed to do the work, but with respect to engineering in general it is open season. Anyone with the will is free to do it.

We don't (at least with some assumptions about jurisdiction) allow people to practice law or hair styling without professional accreditation. Anyone claiming to be those things without the professional accreditation is lying, so there is at least some logic in trying to stop people from lying. But not so is the case for engineer. Not having professional accreditation does not imply the same.

Except in my country we do prevent engineers from calling themselves engineers unless they have professional accreditation, even though we quite happily allow engineers to practice engineering without professional accreditation. It's the stupidest thing.

[lukas099]

Usually software is easier to take apart and modify than other engineering products, so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.

[MadnessASAP]

How quickly a mistake can be corrected is irrelevant. If the software causes a plane to crash it doesn't matter that the fix is quick and easy.

Similarly if the software causes a worldwide outage of critical infrastructure.

In many cases it is imperative that the software be correct from day 0. Just like a bridge.

[lukas099]

But we're talking about the profession as a whole, not just working on planes or critical infrastructure.

[constantcrying]

>Usually software is easier to take apart and modify than other engineering products,

I do not think that is true. The one thing software allows is a large degree of modularity. In Electrical or mechanical engineering everything can always influence everything else. In software you can have very strong boundaries.

>so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.

Why? I don't see that conclusion at all.

[lukas099]

You really don’t think it’s easier to rewrite and redeploy some code than to take fix a bridge or something?

>>so it doesn’t make sense to hold it to the same standard of correctness, and prioritize speed of deployment more.

>Why? I don't see that conclusion at all.

Because, except in like safety critical applications, it’s ok to get something that works most of the time out the door and fix minor bugs later.

[ninkendo]

I think this is debatable, but I understand where you’re coming from.

Personally I think it would be a better world if software were held to the same standards as other engineering disciplines, and we didn’t treat it as somehow less important for software to be correct just because it’s easy to fix. Things would move slower, but we wouldn’t be “spinning our wheels” nearly as much by redoing work and reinventing wheels over and over. A world where software can be considered “done” when it works and is free of bugs sounds amazing to me.

[randomdata]

I see so many mechanical bugs in my farm equipment, I have to question your notion that other engineering disciplines are actually held to a higher standard.

[ThrowawayTestr]

Which leads you to situations like last Friday.

[randomdata]

According to the dictionary, engineer is defined as: A person who designs, builds, or maintains engines, machines, or public works.

You may have a point that the prevailing idea of what engineering is does not recognize software as an engineering discipline as it does not fit into any of engines, machines, or public works. But if we were to include software, surely all software practitioners are people who design, build, or maintain software? Even the web API guy from the story is an engineer on that end.

[constantcrying]

You are totally misunderstanding me. I am not saying that software engineering does not exist, but that most people who are software developers are not software engineers.

If you look at what engineers are doing in other disciplines you will find that in software there are some people doing the same thing. They are doing things like drafting requirements, designing, defining, simulating, overseeing, but don't spend much, if any, time actually building things.

[randomdata]

> They are doing things like drafting requirements, designing, defining, simulating

Which is design; captured in the definition.

You're welcome to invent whatever meaning for engineering you want (although you kind of need to define it, in that case – we can't read your mind), but going by what most people consider engineering to be, either all software developers are engineers or none of them are.

[constantcrying]

>either all software developers are engineers or none of them are.

Why? I have worked jobs where I definitely didn't do any real design and was just there to implement certain things. I absolutely wouldn't call what I did engineering.

[randomdata]

Again, "build" is also captured in the prevailing engineering definition (although software may not be).

What is the significance of you not wanting to call it engineering?

[constantcrying]

>What is the significance of you not wanting to call it engineering?

It conflates two separate things with not a great amount of overlap. It also describes two different paths, an academic path and a tradesman path. The distinction is obviously useful in describing people/roles/activities.

You could also ask why we are conflating machinists with engineers, clearly machinists are building things, definitely more so than engineers.

[jltsiren]

I think "engineer" as a protected title refers more to their status as a professional in the strict sense of the word.

If you are a professional, the norms of your profession override your loyalty to your employer. Your boss cannot override your professional judgment, unless they are also a member of the same profession and willing to assume responsibility. And if something goes wrong, it can be the professional who will be held liable rather than the boss.

[agentultra]

It’s a protected category in my country.

“Software Engineering is the part of Computer Science that is too hard for the Computer Scientist.”

[ghaff]

I think there is a distinction in general. On the other hand, as someone with degrees in other areas of engineering, I also think there can be too much emphasis placed on the degree to which those other areas of engineering apply formal process and rigorous practices to everything they do. Yes, there are established codes for structural analysis and the like but there's still also a lot of seat of the pants.