Following up on my post on “Design”, I’d like to take a bit deeper dive on this whole “engineering” business, because I think the topic is worth an article.

A couple of weeks ago I joked at a company event that our company employs more people who played major league sports than actual engineers. Still, we have a whole department called “engineering”, complete with a guy who carries the burden of having to hand out business cards with “Sr VP, Engineering”. At the same time, I’m quite sure that calling yourself an engineer without actually being a licensed engineer is not legal either in California, where we are headquartered, or in Ontario, where we employ a ton of people (at what we in Canada like to call “our other HQ” ;-)).

I get it why we want to have expensive sounding titles on our business cards, and I can be frank: it sure looks posh, seeing “Principal Software Engineer” below my name on a nicely designed business card. There is also some history: there were times where people were convinced that the way forward in our profession was to look at Engineering, and you can make a case that we probably should; Engineering is a protected discipline because it deals with stuff that is risky in the sense that life and limb of the public is in danger if engineers get it wrong. With “software eating the world”, that is more and more the case for us, too.

But wishing it were true and it being true are two different things. You can’t start calling yourself a medical doctor just because you think you should be one.

Also, putting labels on people influences how they behave, and I’m frankly not sure that at least my nook of the world (Internet/SaaS style stuff) is ready to adopt engineering behaviours or even should be ready to do so. Still, we call you an “engineer” and then you start behaving like one. To me, it seems that that’s the cause for a lot of “overengineered” software that I’ve seen around, especially in my work in North America where abuse of this term seems to be most prevalent.

I’ve thought long about what our job entails, and as I don’t just want to rant let me share my thoughts on what we should call ourselves.

First, let’s make the distinction between what my skills are and what my employer wants me to do. It is subtle, but I think it is important.

My craft is that I program computers, an area I’ve been honing my skills in since ‘76 or so. Therefore I used to call myself a “computer programmer” but since we’ve moved on to distributed systems, then cloud, and now serverless the “computer” becomes a more and more nebulous concept; the second-best term I can come up with is “software developer”, and I think that that’s a nice label. It’s a bit broader, but it is still a pretty precise fit with what I can do and where my specialization lies.

My job is, and has been in the previous couple of jobs, to work with other people towards the goal of developing product. Not necessarily software, because product is software and then some stuff. When I joined an eBay subsidiary in 2007 I had to get used to the term, but I think that the label “product developent” for the departments I’ve since worked in is an excellent match.

So, I’m a software developer working in the product development department of PagerDuty.

Why is this important? Apart from the fact that it avoids muddy legal waters around the incorrect application of the term “engineer”, it is a much better description of what we do and what we’re supposed to do.

We’re not supposed to engineer marvellous structures, or even supersafe software, or stable software, or whatnot. Quality in engineering is pretty much an absolute (sorry, you need that much insulation on your 110VAC cable, no way around it, laws of nature and such); quality in bringing your startup to the next level in revenue might get sacrificed (hopefully temporarily) in favour of quickly whipping out some functionality in order to lure in that 5,000 seat deal.

We’re also not supposed to sit in our cubicles 9x5 and just “program computers”. Our jobs have evolved beyond that - we expanded it upstream towards design and architecture, and downstream towards deployment and operations. We need to cooperate with other people, and therefore our jobs have become much more social than in, say, the ’90s.

We are supposed to advance our company goals by developing its products, though. That will often involve writing code, hopefully sometimes avoiding that (by integrating existing open source or commercial solutions), and most importantly by thinking along with people who are good at product management to shape the roadmap; more often than not, the most effective thing you can do in product development is not writing the best code, but making sure that the plans from “product” and marketing are such that they’re simple to implement. Win upstream and writing the code becomes an afterthought. Seeing ourselves as product developers with software development skills broadens the horizon and liberates us from being “just engineers”. Words matter.