Programmers: Stop Calling Yourselves Engineers (2015)

Contrast with software: Many large software projects fail to even achieve a coherent and feasible high-level spec of what the system needs to do, let alone how all the details will work. Once you get past that phase, you find that the actual design and build of software systems relies on so many layers of abstraction that practitioners have to make a lot of assumptions in order to get anything done. In practice it works because we tend to keep the lower levels stable and coalesce around a relatively small number of proven stacks, but unlike the hard engineers knowledge of materials and physics, the actual platforms are all human defined and subject to change. Imagine how civic engineering would work if physics were just code written by humans that never stopped monkeying with it.

These links were the first I found and they've tested OK. The first is an html version, the others are PDFs with the last being the best quality (in color). If they don't work just search for the title and year.

http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/SciAmGibbs/...

http://sarec.nd.edu/courses/SE2017/Week1-TheSoftwareCrisis.p...

https://www.researchgate.net/profile/Wayt-Gibbs/publication/...

The usual definition of an engineer is someone with a degree in the subject and it's been that way for about a century or more. Most 'sound engineers' do not have one (but there are exceptions). In fact, most of those who I've known have no qualifications in the field at all. That's not to say they're not good at their work (as many are very competent).

SMPTE (Society of Motion Picture and Television Engineers) and the AES (Audio Engineering Society) used to require a degree for membership but I'm unaware of whether they still do or not (as it's a long while since I had anything to do with these institutions). If I recall one could automatically become a member of them if one was already a member of the IEEE (but it required a degree as well for membership). This reciprocal arrangement between professional bodies works when the core training is the same (I recall becoming a member of one institution after it took my name from another, all I did was tick the box and pay the fee).

The question of whether it matters if someone is called an engineer or not is probably only relevant when regulation and safety are involved. For example, my profession is electrical engineering and computing so I shouldn't (and wouldn't) misrepresent myself as a civil engineer and apply for a bridge-building job when that's not my profession (that's to say, I may be in engineering but I'm unskilled in the bridge-building branch of the profession).

Even if I secretly studied bridge building for, say, over a decade and was quite excellent in the subject I shouldn't be allowed to practice that skill without going through the formal accreditation process because when something goes wrong (and sooner or later it inevitably will), the lines of accountability will be dredged out (no pun intended). When this happens it's much easier for all involved to assume [know from one's qualifications] what the skills and expertise of those involved are so blame can be apportioned.

It's hard to imagine a situation where a sound engineer sitting behind a sound desk—or a film grader/editor at a Moviola film editor or its digital equivalent—can do anything that would endanger life so it likely doesn't matter what they call themselves.

The matter of using the term 'engineering' in connection with computer programming is a much more difficult and vexed matter for two reasons. The first is how practical software development actually measures up to other engineering professions, and second, the applications to which software is put.

In the first case there's a solid argument (as per the SciAm article reference I've posted elsewhere to this story), which is that the maturity of software development per se is well behind other branches of engineering (electrical and chemical engineering for instance). The second covers the fields where software is applied, which, as we all know, is everywhere.

Unlike my bridge-building analogy, we've not yet separated out a methodology (a separate engineering philosophy) for critical systems software development from other less critical systems. (It's obvious we need them separated but we still use common tools (compilers etc.) and common programming methodologies and this is a significant problem—I could provide reasons but they are too lengthy to cover here although for those interested the SciAm article is a good place to start.)

Put simply, the level of hardness and granularity of traditional engineering (set by a several-hundred-year long lineage of experience and backed by both domestic and international standards) that goes into hardware design and then building hardware—bridges, rockets, microchips, etc.—is not necessarily backed by the same hardness and granularity from the supporting software. And as we've seen in practice, in many, many instances this has been a major problem.

In my opinion, there will have to be rationalization and standards eventually. When that will happen is anyone's guess.

At least in Canada, the “engineering field” is divided into engineers, technologists, and technicians.

Some people involved in software work at the level of engineers, some work at the level of technologists, and others work at the level of technicians. I think having a finer grained way to discuss the different types of software development would be a helpful way to move the conversation forward.

This would also seem to align with what the article talks about having a richer vocabulary.

If I don't know them I could still do stuff, but the likelyhood of landing in jail because what I planned started a fire or killed someone would be very real.

Going to jail because you managed to replicate a SQL injection that everybody and their dog knows since the 90s is something I really would like to see in software engineering.

Because you know: engineers are personally liable for the decisions they take and for the things they should have known but didn't.

In the same way, the job title shouldn't matter as much as the principles of ethical professionals. Should we really be using job titles to indicate the expectations around ethical conduct?

When I want to do the electrical wiring for a house there are close to 2000 norms each stuffed with formula and details, that I have to get right or I will have to fear the consequences.

When I write software it is more like "Lol this framework looks interesting, lets try it together with that code from coolcoder1982 on GitHub".

I know there are programmers who try very hard to specify and write good software, with formal correctness, tests and so on. And maybe those would be closest to the term "engineer", but there are so many people who just aren't, that the whole field suffers.

When something went wrong due to a software error for the past 3 decades it was (and still is) usually excused as if nobody could have done something to prevent it. Software error. Oh god. Nothing we can do. Jikes.

If my electrical installation starts a fire, I pay or go to jail. If the norm I based it on was wrong and that started the fire, the norm will get changed and everybody from now on has to follow these updated rules. Existing buildings might need to be updated. There are laws specifically regulating how often such checks have to be done. Because this is what engineers do: they follow boring norms, try to apply them to the problem and if they fail they personally suffer for it. In fact all that stiffness, all that lack of fun, all these rules can be seen as the engineers way of surving their career without landing in jail.

Meanwhile as a software engineer you can write code that processes the healthcare data for millions of people, leak all that data through a combination of bad decisions nobody should have made again since the early ninties and still stay a programmer, Buffer overflows, SQL injections, DIY crypto, unsalted MD5 hashing, you name it.

Again: maybe individual people have higher standards (me for example), but the lived practice is so bad, calling it engineering would really border to an insult against those who really put their careers, families and wellbeing on the line in other engineering professions.

If electrical engineering was like programming electrical fires and electrical shocks would be the leading cause of death.