A few years ago, The Atlantic published an article urging software engineers to stop calling themselves engineers. In it, the author goes as far as to say that ‘the title “engineer” is cheapened by the tech industry.’
What are we to make of these claims? Are software engineers real engineers?
I’d like to dedicate this blog to exploring that question in depth.
The Parallels
If software engineers aren’t really engineers, why did people even start calling them that? The answer is the elephant in the room which The Atlantic’s article most glaringly overlooks, that is to say, the common process of problem-solving in traditional and software engineering.
This process is divided into three parts. The first is the definition of the problem, which in other fields of work is often readily provided. Your client will assign you a task, but how you go about completing that task is entirely up to you, and two different engineers may well come up with radically different solutions for the simple reason that they conceived the problem differently.
The second part involves solving the problem within constraints. In traditional engineering, this usually means accounting for real-world forces like gravity and pressure, or the behavior and durability of the materials being used. In the realm of software, the constraints are typically virtual, but they are very much still there – if you want to find a new way to mine cryptocurrencies, you can’t just ignore the limits of available processing power. And there is a great deal of software designed to interact with the real world too, from voice-activated virtual assistants to self-driving cars, which will have to account for real-world constraints.
The third and final part has to do with optimizing your solution. You have your answer to the problem, good, now how can you implement it while spending the least amount of time, energy, resources and money? For traditional engineering this is most often about working within a budget, while with software it has more emphasis on optimizing the code itself – but at heart, it remains the same problem.
This covers the most important similarities between these two forms of engineering. Now, what can we say about the ways in which they differ?
The Differences
Most of the arguments raised by The Atlantic’s article come down to what we may call a difference of professional culture.
A traditional engineer will always have a university degree and some form of postgraduate qualification in the field they chose to specialize in. They will be legally certified and licensed to do their job. This is not necessarily true for software engineers, who may very well be self-taught and have come to hold their position at the end of a chaotic, improvized career path. Software engineers require no special certifications from their governments before they can practice their trade, either.
The Atlantic also argues that traditional engineers are more dedicated to the ethical dimension of their job, which they see as a service to society as a whole. This distinction, however, I find rather blurry and increasingly less relevant. The ethical problems posed by modern tech are constantly being raised by professionals in the field, and I for one have never met a developer who was not concerned about the moral consequences of their work.
Wherever one draws the line, though, it’s hard to disagree that traditional engineering has an established culture – one that values legitimacy based on the collective and a sense of moral duty – which does not have a direct equivalent in tech.
Conclusion
Engineering is a very broad discipline which can involve problems of a very diverse nature, from getting a shower to work on a space station to drilling for oil at the bottom of the sea. The fact that software is now involved in virtually all of traditional engineering’s problems means that a clear line of demarcation is impossible to draw. Someone working on the code that keeps a plane in the air without the pilots touching the controls is unquestionably doing engineering.
At the same time, the messy and often unregulated field of tech is culpable of using the term engineer much too casually. Someone designing a website for their blog is certainly not an engineer, yet it is not uncommon for startups to boast they have four ‘engineers’ in their team in an effort to look more reputable.
The conclusion is that while software engineers are beyond doubt real engineers, not everyone who codes is a software engineer. Moreover, not everyone who codes needs to be an engineer, nor should they be expected to all do work which carries the same gravitas (though everyone should indeed have a sense of moral responsibility for their work).
What we should be pushing for, therefore, is not greater lexical precision but a cultural shift in tech. Let’s keep using the term software engineer, but let’s also make it a bit more of an elite term than it already is. It’s not enough to know Python to call yourself that, but if you’re working on finding solutions to complex problems that have a substantial impact on society and on the lives of the people within it, then have no doubts about it – you are an engineer.
