Some argue that software engineering is not computer science and some argue that it is not even engineering. Maybe they call them “developers” instead because they consider it the more modern equivalent of an “engineer”. I don’t know if it’s that modern; my mother calls “programmers” “coders” and they worked on Cobol, RPG and SystemV – and in hindsight changing the title didn’t make it sound more modern. In an early footnote in her book The psychology of software teams, Cat Hicks refers to the use of the term “developer” more like a placeholder “to be taken as broadly as possible” [1]. That is how I have interpreted it, but I don’t know if that is the general consensus, or in other words, that the title of Developer does not define some subjective and narrow meaning for most people.
Call me an engineer or a developer - I don’t mind either way. There is, however, this one specific argument that sends me into a nitpicking tantrum, because I think it is ill-founded. The argument is that software engineering is not engineering because real engineering involves hard science and, more importantly, great risks, as they build bridges, create skyscrapers and design aeroplanes.
The argument is built on the definition of the term “engineering” so let’s take a look at that. Engineering is described by Sommerville in his book Software engineering as “the practice of constructing using the scientific method.” Earlier, in 1920s, Charles Horton wrote in Opportunities in engineering:
The profession of engineering – which, by the way, is merely the adapting of discoveries in science and art to the uses of mankind – is a peculiarly isolated one.
Who is Charles Horton? I have no clue. I just found his book on the Gutenberg project and was curious. He also reflected on two kinds of engineers when talking about steam engines: those that operate them and those that design them – and despite holding the latter in much higher regard, he identified both as engineers. Then there’s a more modern (2018) definition of software engineering by the Association for Computing Machinery:
It integrates significant mathematics, computer science and practices whose origins are in engineering.
Or the summary on Wikipedia:
Engineering is the practice of systematically applying natural science and mathematics to design and improve systems, devices, or processes that solve problems under constraints.
Hence, when someone is working on a program, using mathematics, evaluating and converging results by interpreting empirical results in a scientific manner, they are being engineers.
In a casual conversation or within a small team such definitions of titles, domains and, perhaps, expectations might not have a meaningful effect. Defining terms is still not completely redundant. Walton frames it well in his book The fundamentals of critical argumentation:
People typically feel that verbal disputes are trivial and that how a term is defined is of little or no importance, compared with the job of proving a point by “hard” observational evidence collected by statistics. But problems about language and verbal disputes are often far from trivial. Biased language is a powerful tool of persuasion on important issues of public policy. (…) In many cases, merely identifying a bias by realizing that the language used conceals an argument is all that needs to be done in order to criticize the argument effectively. [2]
Just today, I listened to Nikhil Suresh’s podcast Does a frog have scorpion nature, in which his interviewee Jesse Alford, ex-Pivotal, reflected on his journey from testing to leadership. He had doubts on defining a position narrowly:
(…) I came into software engineering from a testing background and there was this whole fight about whether or not people should call themselves software testers or quality assurance analysts or software engineers engaged in test. A lot of the more thoughtful long-term teacher, coacher, consultant types just wanted the word tester. But you end up committed to a role that maybe shouldn’t exist. And this is actually where I think programming is right now. I’m not sure that programmer is a good way for jobs to be described.
The subtext was that to take the process of creating software solutions and reducing it to just “programming” eventually leads to needless discussions about what you’re supposed to be doing and, consequently, what you’re supposed to be paid. As a programmer, are you really supposed to sit in front of the computer and produce code? No thinking involved? No questions asked? No evaluation, design, conversations… Just typing code – that’s it?
They referred to an older piece by Patric McKenzie Don’t call yourself a programmer, and other career advice from 2011. McKenzie writes:
Engineers are hired to create business value, not to program things (…)
And:
“Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired.
He advices:
Instead, describe yourself by what you have accomplished for previously employers vis-a-vis increasing revenues or reducing costs.
Nikhil and Alford resonate this in the podcast, as Alford continues about anyone self-expressing their title as a “programmer”:
You know, it lets you out of the most basic version of the trap and people have have a strong appeal for calling themselves that thing because it feels simple and honest, but it doesn’t help you.
And this is like what you call yourself or what you think of your job title as matters more than it should, matters more than we would like in almost.
I can relate to that. The way my previous title “developer” was catered inside the team was with exactly this type of blindsided humility; we were supposed to not care about corporate titles. In a few years, we were sitting in a room together apart from others, churning through tickets, while they designed the product, the marketing, and the strategy.
On a personal level I don’t really care if the title is an “engineer”, “developer” or something else. Semantically, however, it irks me. In practice, I guess it helps to be a little mindful of it especially when it matters, but I don’t think it should be of any real significance in day-to-day work.