We Need a Better Term Than “Software Engineer”`
Words matter, and the two words in “Software Engineer” are both incorrect. Let's move towards something better.
I read Len Martin’s article Don’t Be a Programmer, Be a Software Engineer this morning.
It’s hard to argue with the content. Successful developers must take a holistic view of their job; simply writing code doesn’t hack it. And that surprised me a little, because when I see the words Software Engineer, I generally expect the worst.
During the 80s and 90s, when people ask me what I do, I’d say “I’m a coder.” This was simply a kind of inverse snobbery: at the time, developers had job titles such as Senior Database Analyst or Technical Project Lead.
But I’ve come to realize that what we call ourselves can change our view of what we do.
And calling ourselves Software Engineers hurts us in two ways.
It’s Not About Software
As Leon Martin points out, the goal of developers is not writing software; it’s delivering value to the users of that software.
In fact, a good developer can sometimes manage to deliver that value without actually writing a line of code. Developers occupy a unique position in most companies, sitting at the confluence of many business units and their customers. Developers often have a broader picture of how the company works and how things interact that many of the business’ managers. Many times I’ve seen a manager deliver a requirement to a team, only to have the team respond, “we can do that, but why not just…?”
So, if we’re engineering anything, it’s value, not software.
It’s Not About The Popular Interpretation of “Engineering”
This is where the fist fights break out.
The word “engineer” triggers visions of professionals who use historical information to create things. A structural engineer knows the strength of materials and joints, and knows the various rules (and rules of thumb) dictating how a result can be built. A chemical engineer knows the properties of compounds along with the ways these compounds interact. In popular use, the word engineering means responsibly and economically building from a set of known things. Britannica encapsulates it as “the application of science to the optimum conversion of the resources of nature to the uses of humankind,” which is clearly wrong: no right thinking resource convertors would ever claim what they were doing could never be improved.
A while back, Glenn Vanderburg introduced me to the book To Engineer is Human, by Henry Petrowski, which paints a far more realistic view of what real humans do. Engineers have never been infallible followers of design rule books. Instead, engineers know how things have been done in the past, and then apply creativity to try to do them more cheaply, or more safely, or just plain bigger. And along the way, they sometimes design outside the lines: structures collapse because they cut back too much, medicines have side effects, and so on. (If you want to see Glenn taking about this, here’s a great talk.)
In many ways, the values of the agile movement1 represent this kind of engineering: theory drives experimentation, and feedback decides if the result is useable.
Unfortunately, most middle management buys into the more popular (and in a way more hopeful) vision of engineering as some kind of deterministic process: you feed in a requirement and a bunch of coffee, and out pops a specification, from which comes and architecture, then a design, and then a project plan. If this was a bridge, this is the point where we’d get the laborers working. If it’s software, cue the programmers.
So, by calling ourselves “Software Engineers,” we are reinforcing two incorrect stereotypes: that what we deliver is software, and that if we were any good at it, that would be a mechanical and deterministic process.
.
Words Matter
The people who deliver value by iteratively refining software deserve to have a name for what they do. It isn’t programmer, designer, analyst, front-end developer, or software engineer. It’s bigger than that, and it’s more subtle.
And I have no idea what it should be. But I’m hoping you do.
I’d love to see your ideas in the comments.
Make it fun!
Dave
That’s me on the left…
Something more accurate IMO would be ‘optionality maximiser’, but that’s just me the strange hill I’ve chosen to die on :)
Yes, words matter... but I'm also reminded of a phrase (Frank Lutz used it as a book title years ago): "It's not what you say, it's what other people hear." I recall hearing the "job description" Software Engineer back in the 1970s (Margaret Hamilton is said to have been one of the coiners), and I've thought - intermittently over my career - long and hard about it. At this point... Methinks we're all over-thinking this.
I read Leon Martin's article too, and I agree with nearly all of the salient points that he made, and that you've made above. "...if we’re engineering anything, it’s value..." Well, this can be claimed about any of the engineering professions. The carpenter knows that his drill bit is of no intrinsic value to anyone else... what he's doing is using it to make a hole where one is needed. Civil engineers don't "engineer civils", anymore than mechanical engineers "mechanic", or electrical engineers "engineer electrics" - whatever those might be.
Over my decades in this profession, I've come to realize that we deal with a wide spectrum here... a range of experiences (or lack thereof), of perspective, of talents and training, and of focus. In the '70s (again), we were happy to call ourselves "hackers", when everything seemed shiny and new - like tinkerer-inventors in our basements, we were toying with techniques, approaches, methods and practices, trying to find the "best", or at least what seemed to work well. We also were learning that we could not accomplish most (major) tasks and projects alone - that we had to learn to "play well with others"; thus, teams.
With time came a degree more of proficiency, not that my code at that time could be compared to Ms. Hamilton's, whose programs "engineered" Americans to land on the Moon. But we all - those who were practicing seriously, diligently - were getting better, and the rather demeaning term "programmer" didn't fit well to many of us; hence: "software engineer."
We necessarily had to learn that our results - our product, our solutions - were very different in kind. Unlike a structural engineer's girders and rivets, or a chemical engineer's transformed elements and materials, our actual output cannot be touched, or weighed or measured - by its very nature, software is intangible. This brings an inherent difficulty in communicating the readiness (or lack thereof) of the fruits of our labors to the business-weenies and other non-technical folks ("I don' get no respect!" Pax, Mr Dangerfield!). Trying to help my own software teams communicate clearly with others, I use the metaphors "The veneer of photons..." (they'll only believe it when they can see it), and "User mythology..." (they don't have to understand the particulars or details); still, there's a deep gulf between what coders understand and work with daily vs. what non-technical people understand - if anything - about software (explaining why AI can be sold as snake-oil to the b-weenies).
Back to the point: Our profession exists as a continuum, not just expressed as novice-to-expert, but more nuanced. A youngster who's completed a website coding bootcamp has a start in proficiency with one (1) programming language, a few supporting tools, and a worldview that, with his new "hammer" is convinced that all computing challenges are website "nails". Within a few years of employment, that youngster becomes a midster with a few more tools in his kit and experience with a limited/few more problems solved - he's likely earned the full JD/title of "software developer". A different career path has the youngster go to college seeking a degree in "software engineering" - she's got a good foundation in the academics, theory, maths and science of it all - but upon graduation, she's still just an apprentice, with years of sweat-equity to earn a journeyman's or master's viewpoint, wisdom, skills and expertise.
Point is that, regardless of what we call ourselves - hacker, coder, full-stack developer, application developer, system programmer, software engineer - we've all earned a place on the spectrum of training, experience, expertise and worldview. Hopefully, one is self-critically honest about her or his actual spectral wavelength, and can use an appropriately accurate resumé and professional title for self-advertisement to others.
And there's the rub: How others - especially folks in business (who largely provide the opportunities and paychecks), together with their HR gatekeeper lackeys - perceive (see) us. We can quibble all we want to parse and refine our own notions - developer or engineer - of our profession, but is all this effort communicating the right things to our "audience", the folks we seek to hire us, to provide the next problem and project, and who will somehow, clearly or distortedly, judge our "solutions"?
Unhappily, I think not - not entirely or satisfactorily. I'm currently seeing this through the lens of the recently involuntarily unemployed - I was terminated, laid-off last November from a position of director of application development (or dir/SW-engineering, depending on who you asked in the company). Thus, I'm back in the job market ("I'm available to work" is the LinkedIn tag), and my email inbox is stuffed with possible positions entitled Director (or VP, or Senior Lead) of Software Engineering (most commonly, with SW-Development as a close second), with variations and combinations.
Clearly, upon even casual reading of the advertised job descriptions, responsibilities and experiential requirements, there's little to no agreement upon what any of these positions really is or does. Obviously, the key to an actual interview lies with getting past each employer's HR gatekeeper, now equipped with "AI" to further filter applications and resumés. Fortunately, an unemployment counselor recently coached me that it's okay, even recommended, to use ChatGPT to crank out bespoke resumé-variants and cover letters customized to each job description - sort of a "fight fire with fire" approach that I'd not considered by myself.
It's helpful - necessary even - for us to think hard and debate the "are we really engineers?" question. This shapes our personal and aggregate worldviews and philosophies about this brand new (only 50+ years old) profession. It can lead - more importantly, IMHO - to critical thought about our roles and responsibilities in business and enterprise, and about the codes of ethics and morality (so very important to and cherished by other engineering disciplines) necessary to guide our contributions to our fellow citizens and society.
But let's not fret too much over the badge of "software engineer" - it's no more right or wrong than "industrial engineer" or any other engineering discipline - it's whether or not we live up to our professional obligations that really counts.
Sorry for the TL;DR of this, Dave -- It's what happens when you suddenly become (temporarily, I trust) unemployed, "looking for work"! Oh, and my budget- and income-conscious spouse won't let me become a "paid member" of your blog until I get a job again!