> To me the term didn't come from HR it came from trying to get "programmers" to think in terms of constraints, value, risks etc. Seems a pretty clear and simple definition.

The trend of giving high sounding titles started decades ago as more and more educated people entered the workforce and involves all jobs.

Manager? Vice president.

Secretary? Executive assistant.

Developer? Engineer.

Reports and collects some data for his bosses? Data analyst.

Warehouse worker? Logistics and distribution specialist.

Not to nitpick your point too much, but VP tends to have a specific meaning, even if its given to many employees. Usually, it means that this employee can sign contracts or make certain regulatory commitments on behalf of the company. Its not always self-aggrandizing.

It absolutely does not usually mean that, there are a ton of finance VPs that nobody would ever let sign anything meaningful without someone up the chain reviewing it. There are also tons of people who sign contracts for companies who are not VPs. There are companies where VP is really just about comp; all jobs above $x/year are some flavor of VP, even ICs.

It doesn't have to always be self-aggrandizing for it to be true that lots of people are now called VP who used to just be middle-managers.

There's a joke in finance that VP is an entry-level job. Largely because that field is very status-driven and people want a glorified title, despite entry-level responsibilities.

In medicine doctors are now “providers” no different than nurse practitioners, physician assistants, RN, PT, pharmacists etc. it’s the opposite, leveling everyone to the lowest common denominator

In some countries some profession names are reserved. There you know that a doctor is a doctor, not a guy who went to a hygiene bootcamp.

I remember software engineering courses to be about the process, the metrics available, the way to mesure and quantify whatever is going on in a project.

As opposed to learn about a type of algorithms, some math, some language or some pattern.

10 years latter, I’m glad for the exposure.

It was more useful to understand and talk to folks on the sides of the dev department : security, ops, qa, support. Heck, even product.

I felt that with those, the dev could monkey patch whatever together and still be part of some engineering process.

Now I don’t know. I sure do push code around.

Is there a foundational body of knowledge for software engineering the way there is for established engineering discipline? Something that can be tested against like the FE and PE in the US? Would the FE, for example, suffice?

If not, then, at least in my mind, it seems difficult to pin down exactly how software engineering can occupy a space in the domain of modern engineering.

NCEES tried a few years back and developed such a curriculum but there wasn't enough interest so they got rid of it. IIRC, something like a total of 6 people were certified as a software engineer in the last year it was available. I don't see required licensure for software engineers happening unless 1) it's driven by employers or 2) it's driven by regulators. I don't see #1 ever happening because it's asking the employers to give more leverage to their employees. I'd personally like to see #2, at least on certain safety critical applications.

If engineering is applied science with gatekeeping, I'm frankly not interested.

Some sort of specific liability in the legal code could make sense, though.

Isn't the gatekeeping standardized verifiability and liability? Those are sorely needed in a lot of software endeavors.

I think the difference is one of disposal and retry.

In physical engineering, you really get one chance. If you make a mistake or miscalculation, there is a cost associated with undoing what's been done, as well as trying again.

In software, there is no such additional cost. You can trivially start from scratch, or any point between scratch and here, at any given time. There is no disposal cost.

I think that is a perception, but its driven by not being able to "see" the product of the work.

Security breaches, locked in data (poor dB structure or no direct access) reverse engineering undocumented functionality, even just dismantling supporting infrastructure and migration costs are huge. Another huge factor is when business logic is codified and the knowledge is lost from the business and only temprarily held by transient consultants or developers.

An sap project for a single region for a $1bn per year company can easy cost over $10m and no software is being developed, only config, process change and data migration. Never mind increased staff turnover reduced productivity.

But very few people have the experience and expertise to understand what they are really signing up for.

Just think about a 3d model can do for a construction project and what that would look like for code and you can see how poorly we do this really.

This ignores the vast amount of software that interfaces with physical systems. When software fails and causes a rover to crash into the surface of Mars, there is certainly a cost and one cannot trivially start again from scratch. Same even with software that does not interface with physical systems, like algorithmic stock trading.

If Iec 61508 was applied to all software that would also do it.

(Make software actually be engineered)

I agree, but I think the horse is out of the barn in many respects. It will be very hard to get organizations to adopt such standards without being forced to by some regulatory agency, unfortunately, because that constraints adds cost and impacts schedule.

That's without even considering all the kinds of rules-lawyering that would be applied afterwards.

In some ways physical engineering is more forgiving. Consider the cost of a security breach. A bridge can be rebuilt, but data cannot be unpublished.

The people who were on it when the bride collapsed are pretty tough to restore from tape...