skip to main content

Why Are Software Engineers (Not) Engineers?

published icon  |  category icon programming

Ever since a professor of a neighboring university remarked “I’m most proud of my graduates when they just call themselves programmers"—while he clearly loves his status as Prof. Dr.—I’ve been wondering: is there a thematic or conceptual difference between a programmer, a developer, and a software engineer?

Clearly, the job title indicates some form of status, although I have non idea why, to be honest. At my first job, HR managers used competence matrices to scale their pawns—erhm, employees—across different tracks, which determined the thing we all care about: salary. Each box you were shoved in came with a label, meaning it becomes easy for your peers to guess which box you’re in, making way for the inevitable comparison and unhappiness. Labels like these, from worth less to more, optionally prepended with “junior”, “senior”, “solutions”, “enterprise”, etc1:

  1. Programmer
  2. Developer
  3. Engineer
  4. Architect

In meeting rooms, when the engineer or architect has something to say, you better listen as a mere developer! Of course that doesn’t sound right, but in practice, that’s what’s going own under the hood. The question is: why are we so attached to those words, and especially the term engineer?

For one, because the HR matrices tell us that engineers make more money than programmers. But why, what’s the difference in their day to day job contents?

Many folks interpret the term “programmer” as a bricolage person who just happens to put stuff together, press compile, and voila, it works! Programmers are viewed as chaotic, have no moral compass and supposedly don’t care about ethics or quality. They probably also don’t know how to code and thrive in a team. Then you have your “developer”, a sometimes seen as evolved version of the programmer who is able to read an API documentation and can perhaps “develop” their own.

But what bigger companies really want to hear (and see), is the systematic appliance of best practices, from design board to tests to deployment and long-term support. Both IEEE and ACM, two hugely influential computing learning societies, define software engineering as a systematic engineering approach to software development. Engineers—the real ones—are process experts. They design, divide into subsystems, make prototypes, evaluate outcomes, specify tests, and provide maintenance.

While that all sounds very appealing, it also reeks of a pre-set waterfall process that is almost impossible to change. Then came along agile software development, and suddenly, calling yourself “agile” was more popular than calling yourself “engineer”. We aren’t afraid of change! Got a deprecated API? No problem! Your test suite is falling apart? We’re here to fix that! Prepending agile to the job title software engineer is making fun of the term engineer.

Creating software—to avoid having to use “develop” or “program”—is about exactly that: coping with rapid change. Civil engineers don’t have that problem when constructing a bridge, although of course innovation is also present in that field. Although I sincerely hope they don’t feel as much pressure as JavaScript developers—I’m sorry, engineers—do, when looking at The State Of JS. Rapid change and the virtual process of creation speaks against the engineering part of the software engineer.

So what else? Perhaps an important aspect that plays a role: jealousy. “True” engineers (this is getting complicated) are allowed to call themselves that: “Hi, I’m an engineer.” could be answered by “Oh really, can you show me any proof”, to which the engineer says “Sure, here’s my engineering degree”. In Belgium and The Netherlands, the engineering title ir. and ing. are legally protected. The Dutch word “ingenieur” thus can’t be simply translated to “engineering” because in spoken language you can “engineer” (design/create) a new pancake in your kitchen: it’s frequently used as a synonym for expert or designer.

Certification in terms of a university degree is what truly allows for the title of engineer. But universities have been cheating as well when it comes to luring students in with exactly that. I studied informatics (literally translated), which is called computer science (CS) at other universities. I can’t legally call myself an engineer. But nearby universities started integrating an engineering degree in the CS programme: if you study CS there, you also get a civil engineering degree. They successfully managed to convince hundreds of students to opt in, thereby stealing funds from less pretentious universities. STEM education, another recent and very hip phenomena, plays out its E letter very well.

That means both universities and companies play a part in the pretentiousness of the title “engineer”.

There have been plenty of efforts to formalize the software engineering field, for instance by the rigid enumeration of requirements. We all know that simply doesn’t work in this virtual ever-changing tech industry. Even IEEE/ACM and ABET university accreditation program attempts are futile: the design, publication, and approval process takes so long that by the time it gets green light, there’s need for a revision. If you read those papers (don’t, but I have to), this is effectively what is happening since 2004. To make matters more confusing, software engineers can be members of IEEE, the Institute of Electrical and Electronics Engineers (you know, the real ones).

Confusing job titles aside, we all agree that programming involves much more than typing code on a keyboard: it requires thinking ahead, dividing tasks into sub-tasks, rigid (and hopefully automated) testing, re-writing and re-designing, optimizing, packaging, deploying, … Some say that this is the difference between a programmer and an engineer, but I beg to differ: a programmer is of little use if all they can do is code. While most physicists and mathematicians also “program” (who doesn’t?), they care less about code quality and long-term support of that code. There’s a big difference between programming throwaway code to execute experiments and a huge software application that gets rolled out to thousands of customers.

It all started to go wrong in the sixties when the term software engineering was introduced by the NATO Science Committee that initiated engineering conferences dedicated to software creation. The conference report stated:

The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.

Provocation, really? By replacing “development” with “engineering”, the whole endeavor suddenly was elevated to a true discipline (cough).

In Silicon Valley, everybody’s born an engineer. Heavyweight champions like JBoss and Glassfish together with the banking industry have turned software engineering into enterprise software engineering. Academic researchers that wanted to distinguish themselves from other computing researchers turned it into empirical software engineering. And then HR managers invented yet another step on the career ladder with engineering architect.

When I call myself software engineer, I suddenly get more respect from big companies. I can only conclude that the title software engineer is a piece of recent cultural heritage that originates from jealousy and pretentiousness, only made worse by the tech industry and its hiring process. If engineering is the application of scientific and practical knowledge to invent, design, build, maintain, and research, then of course software engineering is engineering.

Except that it isn’t.

  1. Let’s not get started on the ridiculous “engineering manager” thing. ↩︎

I'm Wouter Groeneveld, a Brain Baker, and I love the smell of freshly baked thoughts (and bread) in the morning. I sometimes convince others to bake their brain (and bread) too.

If you found this article amusing and/or helpful, you can support me via PayPal or Ko-Fi. I also like to hear your feedback via Mastodon or e-mail. Thanks!