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.
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.
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...
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.