Dont care anout certification, but when you can "engineer" a solution that takes account those three factors you can call yourself a professional engineer.
Certain engineering standards require managed competencies, eg functional safety and equipment for explosive atmospheres, certification is probably the easiest path.
Most people who say, "meh but we are engineers because we make stuff" really don't have the first clue how engineers do engineering.
But I have all the same training in both scenarios. Why would I be "better" at engineering if I'm looking at fiber cables or an AC generator but not python? I learned the same techniques, the same safety practices, the same thinking models.
McKinsey’s found that 98%+ of construction projects run ahead of timeline, and 80% run over budget.
Software engineers also have those requirements, but we try to keep our estimates to small chunks instead of 5+ years.
You're a P.Eng when you can pass your country's certification. That's it, it's just a title.
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.
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?
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.
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.
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.
Maybe we should acknowledge that it’s not as simple to define and that’s why articles like the one posted are writen.
If only this were true for 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.
I believe the laws differ by country. In the above circumstance where I am based (Australia) the person who signed off after reviewing the suspension design would inherit 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.
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.
This is unlike programming, where "self-taught" or "dropped out of college" is sufficient.
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.
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.
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.
Also any kind of automation that might kill a human: industry automation, self-driving cars, etc.
A software engineer builds/architects complex systems in an efficient manner that utilizes a set of standards to do so. Software engineers actually use data structures, complex algorithms and engineering paradigms in their solutions.
A programmer does rote/formulaic (sometimes simplistic) work. Installs and customizes Wordpress sites with basic PHP monkeypatching. Cobbles together UIs with UI libraries and prebaked components. Builds COBOL and FORTRAN applications. Etc.
It's an arbitrary distinction and slightly biased; but one that I think fits. Both are needed and have places in the careerscape, but their utility is different. Much like a civil engineer and a safety inspector are both necessary, despite only one utilizing "engineering principals".
Sure, if you're working on medical devices or in-vehicle electronics or software controllers for nuclear reactors or whatever, that might be the case. But, as a fraction of the software industry, that's tiny. I don't have hard numbers on this, but you can look at popularity of programming languages as a proxy. Most software "engineers" do JavaScript or Python, two languages you would never ever use for such things.
Most software is a form of entertainment with a small amounts of usefulness sprinkled in, or doing things that could, in principle, be done with paperwork.
Since it's a controversial word and opinions vary, why not just say "developer" or "programmer" instead?
A handyman is also an engineer by your definition, but insisting on that title would probably raise eyebrows too.
But to me, engineers are people who build important stuff, that a lot of people rely on, and for which there will be severe consequences if it is built wrong. A lot of software falls into that category. Words evolve, I don't feel like I'm putting on airs describing what I'm doing as engineering (sometimes!), and hence I don't feel like some kind of pretender describing myself as a software engineer.
Also, there's a quote I love, although I can't name the source: "engineering is about tradeoffs". Well so is software development, all day every day - in fact it's the mark of real experience knowing where, when and why to make those tradeoffs. Sounds like engineering to me.