I haven't seen a certification system that wasn't either a money-grab (product-specific certifications, like Windows or Novell), a power-grab (by someone like the IEEE, where the tests were half electrical engineering and the software bits were garbage practices from the 70s and 80s), or a way to artificially restrict the number of available practitioners (arguably another money-grab).

No certification system is going to magically make large systems easier to write or whisk away bugs. Writing software is hard. It's that simple. People who have spent their entire careers writing software, from industry luminaries that you read about every day to the really, really good engineers you've never heard of, who are absolute wizards, these people are still writing howlingly bad bugs because writing software is hard.

You can have your certifications and legal requirements for training and so on, just don't pretend they will improve the state of the art. The best you can do is hold people's feet to the fire after they make mistakes, and if the best people in the industry can't be perfect, why would we expect threats of punishment to fix anything?

Engineering is about designing and building systems, usually with cost, time and reliability constraints. It's totally separate from whatever liability framework is being enforced this week.

The only thing I'm aware of that seems to actually work is to hold engineers accountable for results and give them the autonomy to set their own process. I would argue that even very rigorous methodologies like NASA's Systems Engineering[0] process match that description.

[0] https://www.nasa.gov/connect/ebooks/nasa-systems-engineering...

I am a "Software Engineer". I hold a Professional Engineer designation by APEGS, my schooling was for Software Engineering. I advocate for regulation in the industry but also don't think it needs to be sweeping and catch-all.

My job has me working within Industrial Control environments. Programming mistakes can kill people or damage equipment worth millions. When I receive a software package from someone I want to have some trust in a system that this person wasn't hired off the street for lowest wage. My employer has a good reputation in our industry and is asked to come clean up messes from programmers overseas who provide a bad system and walk away from it.

If your job doesn't have you playing with lives of people or holding the wellbeing of a company in your hands then regulation shouldn't be as stringent. But to say that every project of that magnitude has an Engineer overseeing and holding responsibility over it isn't overreaching imo.

OTOH, not every engineering project requires a PE - and the same would be true for programming as well. Unless money, lives or other regulatory items were on the line then a PE would not be required. That would still leave the overwhelming majority of software not requiring any form of certification for its creators. So there's that.

In my view, "engineer" is getting harder to define. At my workplace, anybody who does anything techy and has a degree is an "engineer" if in the product development department, or a "scientist" if in R&D. Only a small handful of the engineers do what a traditionalist would recognize as "hard" quantitative engineering. Most of the work is fitting building blocks together, troubleshooting, bureaucracy, etc.

Must be the tits.

Doesn’t mean people won’t question your abilities but it helps with signalling

Maybe it isn't yet, but I hope that there will come a day in my lifetime that it is.

With such a list, one would hope software engineering becomes a protected title

Engineering is a field where we understand the fundamentals. Changes from year to year or even decade to decade aren't going to uproot half of the things you know about it. In software that can very much be the case.

A "sailor" could be a captain, cook, look-out, marconist, machinist, steward,... anyone who's enlisted on a ship doing a set of tasks to keep things going.

Is a technical writer a software engineer then? I would say so, yes. Why? Because they are involved in an intrinsic part of the entire process of building and maintaining a piece of software.

The problem with "software engineer" as you frame them, is that you also raise the bar to an incredibly high to attain level as things stand today. Why? Because of how the field has kept on compounding ever more complexity over the past decades. It's extremely hard for mere mortals to memorize a a vast and ever changing corpus of knowledge and experience, be able to dive deeply in any codebase and understand all the parts while also have time left to write detailed, readable and understandable technical documentation.

Case in point: Virtually everyone has a gazillion tabs open with an equal number of googled StackExchange posts.

To keep up with the analogy: I don't think the radio-operator will act as a navigator; and neither does the navigator know the fine details of how the innards of a radio look like.

Hence why you most software engineers are specialists in their trade. And often, specialists in a small fraction of the entire knowledge domain.

Regardless, software engineers are without a shred of doubt programmers. Programming is exactly that: feeding a Von Neumann machine a list of instructions in order to "make it do" something. No more, no less. It doesn't matter what your role is in that process - defining the problem, working on an instruction set, typing the instruction set into the machine, documenting the instruction set, verifying the output,... - you're basically a programmer.

The primary reason why we call ourselves "software engineers", really only is because Margret Hamilton - thé Margaret Hamilton of the Apollo AGC computer - came up with the label in order to legitimize the work she and her team did at NASA:

https://en.wikipedia.org/wiki/History_of_software_engineerin...

In fact, the rise of complexity has caused a "software crisis "in the late '60s to '80s. And it was named as such: a "software crisis":

https://en.wikipedia.org/wiki/Software_crisis

All that is old becomes new again. The more I read about the history of our discipline, the more I'm convinced that we are just chasing our own tails over and over again.

Arguing over who is a "programmer" and who is a "software engineer" is - ultimately - basically arguing over semantics and marketing.

At the end of the day, the world doesn't care how the pie was made. They simply want to be able to fly safe, watch TV and file their taxes efficiently.

It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes. – Keith Braithwaite

This is analogous to, for example, a civil engineer certifying a bridge for a certain load with a safety factor.

If you're programming, you're a programmer. Or a coder. Or a software developer. Or a software engineer. There is no consensus on the distinction between any of these things. Just lots of people with opinions because it's easy to have an opinion on.