Software engineers, or software developers?

One of the age old questions in our industry is "are we software engineers, or are we software developers". We want to be "engineers", because it sounds more worthy... but in this piece I'll argue we're actually "developers".

I’ve been doing some more writing lately, and I’ve been trying to standardise the nomenclature: is it “software engineer”, or is it “software developer”. Or “software engineering”, or “software development”.

Given that the only (good) joke in this industry is: “There’s only two hard things in computer science – naming things, cache invalidation, and off-by-one errors”, it’s telling that “naming things” is right in there. We can’t even name the industry.

First of all, let’s do some data. Google Trends in the UK shows “software engineering” slightly edges out “software development” with a score of 89 to 81 – i.e. it’s a roughly-a-tenth more popular. “Software engineer” and “software developer” get similar scores. On the data, it should be “engineering”.

It’s clear to anyone in the industry that those terms mean distinct things, and usually people will say that “engineer” is a more practiced and deserved skill. But, there is a huge inconsistency in how we describe ourselves as a collective. We have “DevOps”, not “EngOps”. We have “dev teams”, not “engineering teams”. We are “development”, not “engineering”. Even Microsoft call it “DevDiv”. The only time anyone ever says “engineer” over “developer” is when they’re trying to make a point.

Could this inconsistency come from Anglicisation? On Google Trends US, the same test above gives scores which are exactly reversed – 89 to “software development”, and 81 to “software engineering”.

I’ve been writing software professionally for nearly 25 years. I have no idea what that statement means. I have never gone to a client and told them I’m going to apply engineering concepts when I produce software for them. I find it difficult that we can say that we are “engineers” in this sense, because our job titles are not protected and our industry is not regulated. If you say that you are any other type of engineer, it usually means that you are operating under regulation and/or licence.

Shortly I’m going to come down fairly hard on calling ourselves engineers, but before I do -- what we do isn’t engineering anyway. Whatever you think it means, engineering doesn’t really fit the process of producing software. If you build a bridge, you’ve built the bridge. Maintenance is just looking after it. The process of writing software is not really ever done. It is, as the name suggests, developed over time. The organisation invests in the software and we write it, but we keep on writing it as the organisation continues to invest. It isn’t an “engine”, or a “machine” – it’s “software”.

I think the reason why we end up with this confusion is that fundamentally, we know we’re not engineers. We know that we are not “engineering” things – we’re just writing software, and the thing that it is, the value it provides, just evolves and develops over time. But somewhere we wanted to say that we were “cooler” than that, that what we did was as worthy as building a bridge, or a plane. I think we forget to wear the mask of engineers, so when someone says, “shall we call it ‘DevOps’?”, or “shall we call it ‘agile development’?”, we forget, and before we say, “no wait! It’s supposed to be ‘EngOps’!” we’ve just gone along with calling ourselves “developers” again.

The power of banning the word "bug"

Software developers don't think twice about referring to "bugs", but customers don't care about what causes there issue. They just want their problem understood, and a solution put into place. Banning the word "bug" is a very powerful move.

It's 2018, and it's time to use TypeScript

TypeScript can have a profound, positive effect on making complex JavaScript codebases easier to maintain. You definitely should be using it, regardless of where you sit on the static vs dynamic-typing debate.

Share

Our evolving "Digital 247" Software Architecture Methodology helps us guide our technical leadership. We maintain it
in two forms — a benchmark that you can fill out to get a feel as to where you are with regards to your
peers and competitors, and a 7,000-word downloadable white paper that is free to download and is full of
helpful information and advice.