Software engineer : an engineer who makes software
Sometimes I need to recruit people to create software. I do try to be clear about the type of person I’m looking for and the range of activities they would be doing. And I’m sure there’s always scope for me to improve those descriptions. But for software engineers I think one really powerful part of the description is given in the title. If you’re starting to explore the world of software jobs I hope this article helps. I’m writing it because sadly I still see many applicants who are developers that know the syntax and semantics of code very well, yet haven’t grasped the most important characteristic they will need to display.
Engineer. I can be guilty of skipping over it myself. It sounds like a filler word doesn’t it? Like fast food restaurants are reputed to advertise for ‘sandwich technician’, or a rubbish (trash) collection company might employ a ‘waste removal specialist’. Those are important jobs in our economy, but I don’t think anyone believes that the words ‘technician’ or ‘specialist’ really tell you anything about the activity.
By contrast if I advertise a role with engineer in the title it is because the tasks to be done truly need someone with the mindset of an engineer. I believe that keeping such a mindset requires strength of character because, as software engineers, our coding activity has a sneaky habit of stealing our brainspace [I’d like to write more on that in later articles] and causing us to forget that we should be driven by one straightforward concept: good engineering means meeting needs. I think the best engineers are the ones who understand this at a fundamental level, independent of their specialism, and don’t forget it no matter how deeply engrossed they get in their domain-specific tasks (like writing code).
How can an engineer be sure they’re getting this right? Sadly they can never be certain, but I believe there are ways of thinking that maximise the chances. This is because, broadly put, the needs of any engineering project fall into a predictable set of categories. These are: capability, correctness, resourcing, user experience, and stakeholder engagement. This isn’t a new list. You can find variants of it in the works of Shewhart (1931), Deming (1988), and Ishikawa (1985). All of which are great classics and none of them confined to software. For a software-specific take on the same thing I would highly recommend The Pragmatic Programmer by Andrew Hunt and David Thomas, and their concept of ‘good enough software’.
A good engineer knows they must consider deeply all of the categories in the above list. Here are imaginary (but all too common) situations in which software engineering projects might fail because one or more of the categories are ill-considered. The relevant categories are listed after each one in brackets.
- Someone creates the most beautiful maintainable unit-tested code with loads of features but runs out of time to finish because there was only a budget for a quick proof-of-concept. (Resourcing versus capability and correctness)
- A team design a safety-critical system in a hurry and cause an accident due to errors in the code. (Correctness requirements versus resourcing)
- A product needs to be maintained for 50 years but to keep up-front costs down the creator writes spaghetti code using lots of copy-paste and few tests. (Resourcing not considered deeply enough — maintenance costs will eclipse any small saving made during creation. This phenomenon is sometimes called technical debt.)
- A beautiful piece of software is created and end users enjoy working using it, but system administrators find the process required to install it very frustrating, so it rarely gets deployed. (Stakeholder engagement)
I hope that software engineers consider themselves engineers first and foremost, because that’s how humanity creates things that best meet our needs.
I wish I could tell you that I always consider all of the categories above whenever I should, but there have been many times when I’ve missed things. All I can do is strive to get better. To remind myself you’ll see that my bio begins simply with ‘Engineer’. Any knowledge of code and algorithms I may have is secondary to that.
