Don’t Skip, Hot Take

Hot take: most software engineers are not good at their jobs. The standards in software development are too low, causing real damage to real people. While in some cases, this failure is caused by a lack of ability. In most cases, it’s caused by software engineers being unable to name – let alone describe or act on – their responsibilities. Software engineers focus on what they know, on what they are told to do by others, on what they like to work on, and remain blissfully unaware of their responsibilities for other parts of their job. Or worse, willfully ignore them.

Hi! Don’t worry; despite the accusatory tone of the paragraph above, I’m a nice guy and mean well. In fact, this blog is the first part of a series of blogs that I hope will help you, the reader, understand software engineering better. But to improve the future, we first need to accurately assess the present.

I’ve been working in software development for a relatively short time - 8 years. In that time, I have worked for a fair number of companies and seen many projects end, either successfully or more in a “crash-and-burn” kind of way. All in all, I’ve formed a pretty solid image of what I think the responsibilities of a software engineer are and why those responsibilities cannot just be handed over to some other actor in the software development chain.

Let’s start by using a metaphor. Imagine that a doctor is treating a patient for a broken bone. During treatment, the doctor learns that the patient is also suffering from a deadly virus. The doctor does not provide that patient with a life-saving treatment for that virus, because “the patient nor the hospital board asked for it”. Instead, the doctor focuses on the broken bone. What happens? Well, the patient dies, and we expect the doctor to be fired, sued, and/or worse.

There are hundreds of other scenarios, but basically, we expect our doctors to not only have relevant medical knowledge but also to:

• be proactive instead of reactive;
• behave professionally and ethically;
• be transparent and able to explain relevant information, so both the patient and the hospital can make solid decisions;
• consider the needs of the patient and the hospital;
• take responsibility for their actions because they are the experts.

Alright, that seems simple enough. How does this translate to the world of software development? To answer that question, I think it’s prudent to first make an important distinction. Not all people who create software share the same responsibilities. And I don’t mean the difference between product owners, scrum masters, analysts, testers, developers, etcetera. No, I mean the difference between different types of developers. Within the context of expected responsibilities, I think we can divide developers into three broad, fuzzy categories.

Firstly, the coder. This is someone who writes code or scripts that achieve simple, clear goals. Maybe they do so as part of a larger software application, or maybe the end goal is just a singular script to run once or twice. Coders are not necessarily less experienced than the other categories, but the scope of their final product is just way smaller.

Next up, we have the programmer. They still write code, but the code is interactive, more abstract, more generic, and usually, they work as part of a larger team or at least the assumption exists that someone else will continue working on the code at a later stage. They deliver “features”, not code.

And finally, the software engineer. Software engineers are responsible for one or more applications within their contexts. This means engineers need to think about maintaining the applications, make on how the application can grow and evolve, and decide which metrics matter and why. What engineers are building is software and working software is more than just blocks of code or a collection of features. They always focus on a complete solution.

Clearly, we cannot (and do not) expect coders and programmers to have the same responsibilities as engineers. But in the end, delivering code or delivering features without delivering working software usually does not help – or even harm – the end user. The software engineer has a unique responsibility here. And as you have no doubt understood by now;  this means that the software engineer is very comparable to the doctor from our metaphor above.

In short: a software engineer should never use “you never asked” as a defense. Because the “you” in that sentence was not the one that should have asked; the software engineer had that responsibility.

The engineer has a unique perspective that forces a different, more in-depth approach than just the responsibilities of a programmer or a coder. In the following articles in this series, I will look at those responsibilities that a software engineer has.

I will discuss code quality, software quality, and ethics. These three topics can be divided into many smaller responsibilities; requirements and documentation, code quality, maintainability, the software development process, infrastructure, operations and support, analytics, security, efficiency, costs, the impact of the software, and more. And yes, we will be discussing all of that.

Now, I know what you’re thinking. It is unreasonable to expect someone to have all that knowledge and all those skills, right? I’ll be honest: that is the expectation that I have, and I don’t think that makes me unreasonable. I fall short of it myself, so I continue striving for that higher bar. But there are also ways to shore up your shortcomings, and I will share those too, in the form of links, tips, and more helpful metaphors. I hope to inspire you to continue improving yourself, and to make it somewhat easier to do so.

During this series, we will join Alex, a fictional software engineer working on a fictional software solution for a fictional company that provides on-site and online workshops. Alex will help illustrate why software engineers need to do better. The field of software development is young but young and responsible are not mutually exclusive at all. And like us, Alex will discover new responsibilities, and grow as a software engineer.

For a glimpse into the future, an overview of what has already been posted and what is still to come:

• Writing Quality Code (part 1)
• Writing Quality Code (part 2)
• Building Quality Software (part 1)
• Building Quality Software (part 2)
• Creating Ethical Software (part 1)
• Creating Ethical Software (part 2)
• The Development Process (part 1)
• The Development Process (part 2)
• The Software Engineer Oath

Most importantly, I ask you to contact me. Send me your corrections, provide suggestions, ask your questions, deliver some hot takes of your own, or share a personal story. I promise to read it, and if possible, will include it in the series.