They don't need to be especially talented engineers, but, in my experience (and I actually have quite a bit of it, in this area), they need to be dedicated to a culture of Quality.
And it is entirely possible for very talented engineers to produce shite. I've seen exactly that.
That’s in fact the thesis for the entire Deming management philosophy, and in line with what I’m saying (you can produce high quality with a good process or a good culture, you don’t necessarily need high caliber individuals)
In my case, the company produced absolutely top-shelf stuff, but even relatively mediocre companies did well, using Deming’s techniques. It required that everyone be on board, wrt the culture, though.
But I have found that a “good” engineer is one that takes their vocation seriously. They may not be that accomplished or skilled, but they have self-discipline, humility, and structure.
I’ve met quite a few highly-skilled “not-good” engineers, in my day. I’m embarrassed to say that I’ve hired some of them.
[citation needed]
> software quality doesn't appear because you have good developers
Good developers are a necessary ingredient of a much larger recipe.
People think that a good process means you can toss in crap developers, or that great developers mean that you can have a bad process.
In my experience, I worked for a 100-year-old Japanese engineering company that had a decades-long culture of Quality. People stayed at that company for their entire career, and most of them were top-shelf people. They had entire business units, dedicated to process improvement and QA.
It was a combination of good talent, good process, and good culture. If any one of them sucks, so does the product.
No one is working on quality, everyone works on new features. There is usually no incentive to increase quality, to improve speed, performance, etc.
If this industry wants to be respected, it should start trying to be actual engineers. There should be tons and tons of standards which are enforced legally, but this is not often the case. Imagine if there were no real legal guardrails in, say, bridge building!
edit: and imagine if any time you brought up this issue, bridge builders cockily responded with "well stuff seems to work fine so..."
When it comes to safety stuff (like bridge building), there are (and should be) strict licensing requirements. I would have no problem requiring such for work on things like medical equipment, We already require security clearance for things like defense information (unless you're a DOGE bro, I guess). That's a bit different from engineering creds, but it's an example of imposed structure.
But I think that it would be ridiculous to require it for someone that writes a fart app (unless it's a weaponized fart app).
What is in those requirements then becomes a hot potato. There are folks that would insist that any "engineer" be required to know how to use a slide rule, and would ignore modern constructs like LLMs and ML.
I'm not kidding. I know people exactly like that. If they get authority, watch out. They'll only "approve" stuff that they are good at.
On the other hand, if the requirements are LeetCode, then it's useless. A lot of very unqualified people would easily pass, and wreak havoc.
From what I can see, the IEEE seems to have a fairly good grasp on mixing classic structure and current tech. There's some very good people, there, and they are used to working in a structured manner.
But software has developed a YOLO culture. People are used to having almost no structure, and they flit between organizations so rapidly, that it's almost impossible to keep track of who is working on what.
The entire engineering culture needs to be changed. I don't see that being something that will come easily.
I'm big on Structure and Discipline. A lot of it has to do with almost 27 years at a corporation with so much structure that a lot of folks here, would be whimpering under their standing desks.
That structure was required, in order to develop equipment of the Quality they are famous for, but would be total overkill for a lot of stuff.
I do think that we need to impose structure on software supply chains, though. That's not something that will be a popular stance.
Structure is also not cheap. Someone needs to pay for it, and that's when you become a real skunk at the picnic.
IMO this should be the standard - software engineer should be a protected title, and everyone else would be titled some flavour of software developer or similar.
Now I'm not an engineer nor at all aware of what these standards actually mean, I'm sure they're pretty common sense and nowhere near as detailed as bridge building standards.
This, exactly this! I am a retired Aerospace engineer. 8 years of engineering studies at college and 2 years of work study before I was hired.
My son considers himself a "software engineer" and I have told him many times that he is NOT an engineer. He was homeschooled (so, pat my back there), never went to college, never studied programming at all. Yet he makes between $200K-$250K per year, 5 TIMES what I made as a Senior Engineer at Boeing. smh