I'm a non software engineer so maybe I do have a chip on my shoulder, personally I don't really have a beef with what people call themselves, however I will say the distinguishing factor in my opinion between software and the broader engineering world is liability and the culture that exists around that. I am professionally held liable for any work I perform while calling myself an engineer. There can be potentially very serious consequences if I am found to have been negligent or to have not followed best practices.
In most parts of the software world I don't think there exists similar circumstances. I'm not sure if there are agreed industry best practices or certification requirements for most types of software development.
I am both a software "engineer", and have separate non-CS engineering degrees.
What the vast majority of us in software do is not engineering. I think like you say liability is one part, but another big part is the immense breadth of unknowns we have to deal with and accept, but never really chase down. There's no budget or time given for properly figuring out and scoping a project (for most programming), because the penalty for failure isn't so steep. It's not written in blood, so we don't dedicate the resources necessary to really engineer it.
Some programming is arguably engineering. Many parts of aerospace for example. Some of the medical devices space. But it's overall a very small percentage of total programming happening in that world.
And you know, that's probably okay, for now at least.
Based on your description a surgeon would also be an engineer.
The real meaning for engineer is someone who builds complex stuff that require years of learning and practice for the majority of the population.
Having a set of defined rules to follow is not engineering, is safety based on previous experience, most car drivers also do that and they are not engineers.
>Having a set of defined rules to follow is not engineering
It is a part of being an engineer, but it is not the entirety of the profession (I'd probably use the word Standards rather than rules). I think the software world has standards to for things like networking etc - does it count as a programmer following a set of rules if he writes networked software? Maybe...
>The real meaning for engineer is someone who builds complex stuff that require years of learning and practice for the majority of the population.
I don't think this really fits either. Throughout my career I have spent very little time building anything, a large amount of the work is optimizing existing problems/products/processes (this is where tradeoffs the GP mentioned comes in) "How can this be made cheaper, How can it become more efficient, How can it be made lighter etc."
If I had to come up with my own definition it would be something like "Engineering is solving technical problems within an applied set of Constraints" - That probably does not apply to a surgeon - but could be applied to software.
It's not true for most engineers in industry. It isn't just software.
If a car has a poorly-engineered suspension and a wheel breaks off and someone gets killed, does the engineer at Ford who designed it get sued personally? Absolutely not. Did any engineers at Ford who designed the Pinto suffer personally for their design? Of course not.
>If a car has a poorly-engineered suspension and a wheel breaks off and someone gets killed, does the engineer at Ford who designed it get sued personally?
I believe the laws differ by country. In the above circumstance where I am based (Australia) the person who signed off (edit: certified) after reviewing the suspension design would assume the liability. And may get taken to court where you would need to demonstrate you followed best practices may be ask to supply calculations etc.
For example my company we are required legally to keep things like calculations and technical drawings on file in archives for things like above hypothetical.
But the engineer would likely be deposed and, if the case goes to trial, called as a witness. That might not translate well for his future at Ford, or at another employer.
Surprising that no one in this thread has mentioned education as an additional distinguishing chracteristic. Programmers are frequently self-taught. If PG essays and HN submissions/comments are any indication, many programmers dislike school. It is said that programming only requires very basic math skills. There are requirements on professional engineers that do not apply to programmers. Engineering, in the US at least, is generally a regulated profession. That's the point of difference, irrespective of whether programmers perform similar work.
NB. When I use the term "regulated" I mean there are licensure requirements. For example, an exam.
>Engineering, in the US at least, is a regulated profession
No, it's not. Civil engineering is; the rest of them, not so much. The vast majority of engineers in the US fall under the "industrial exemption", whether they work for Microsoft, Google, Ford, GM, Boeing, or General Dynamics, or countless other companies large and small. Almost none of them have a Professional Engineer license.
It's weird how, every time this kind of discussion comes up, civil engineers keep trying to tell all the people who design fighter jets and cars that they're not "real engineers" because they don't have a license.
It's true one may not need a professional engineering license in automotive, aerospace, and some other areas, but one still generally needs to meet certain educational requirements, e.g., an 4-year engineering degree from an ABET-accredited or otherwise reputable institution.
This is unlike programming, where "self-taught" or "dropped out of college" is sufficient.
I wish it was, instead we have people around the team pushing people to cut corners, and engineers tinkering hacks to get along.
To be fair I don't think we even have the tools to create software that we can be liable for yet, not without halting progress to a point where, without strong laws, companies cutting corners would win by iterating way faster.
I am both a software "engineer", and have separate non-CS engineering degrees.
What the vast majority of us in software do is not engineering. I think like you say liability is one part, but another big part is the immense breadth of unknowns we have to deal with and accept. There's no budget or time given for properly figuring out and scoping a project (for most programming), because the penalty for failure isn't so steep. It's not written in blood, so we don't dedicate the resources necessary to really engineer it.
Some programming is arguably engineering. Many parts of aerospace for example. Some of the medical devices space. But it's overall a very small percentage of total programming happening in that world.
And you know, that's probably okay, for now at least.
Agreed, in practice there isn't much liability for software engineers. De-jure however there actually is, even to the point where insurance companies like Hiscox offer specfic policies for freelance/contracting software engineers.
Mostly the harm a software engineer can do will be in monetary losses and not in the loss of life. Also there is the fact, that a lot of the software written will be the process of communication, sparring, feedback and iteration so establishing that a single person is at fault would be hard to prove anyways.
However there are software devs that do have to tread with care (eg. in the automotive sector, defense or medical). The differentiator IMO is who is driving the demand for covering possible liability issues: The private sector or the government.
That by itself (or the cultural differences) shouldn't define what "Engineering" actually means, or should it?
> Mostly the harm a software engineer can do will be in monetary losses and not in the loss of life
Software engineering as a profession is so immature that we haven't seen many serious incidents yet. But people have died because of bugs. And this will only increase over time as we keep using more and more software.
In most parts of the software world I don't think there exists similar circumstances. I'm not sure if there are agreed industry best practices or certification requirements for most types of software development.