What is a software engineer?
There are many ways to refer to people who create and maintain software.
Coders.
Developers.
Programmers.
Crafters.
Early on in my career, I was advised to always refer to myself as an engineer. I didn’t fully appreciate why; I just thought it sounded better and would command a better salary, so I stuck with it.
But is there a better term?
First, we must understand what it is we’re doing.
At its core, I believe it is helping people.
Whether it’s ourselves, friends, family, or customers, we build software to make life easier and more joyful.
After all, technology, properly defined, is just a better way of doing things.
We want to do things better.
Doing things better generates value.
Some value can be delivered today, like when we ship that feature.
But much more value can be generated by being able to change our software in response to what happens tomorrow.
As
says, we’re paid not for what we’ve done, but for what we can do next.1“Good” practices such as clean design, reliable test suites, and up-to-date documentation all make software easier to change tomorrow, and thus more valuable.
This future value creation must always be balanced by the need to deliver enough value today to survive until we can reap the rewards. Beautiful, easy-to-change software is worthless if no one is left in the company to use it.
So what is software engineering?
It’s not just developing new things, but also maintaining the old.
It’s about knowing what not to program.
It’s more than crafting something beautiful—sometimes, we need to hack the ugly thing to make the impact that matters.
Software can do anything. But there are always constraints, even if those constraints are the known laws of physics.
Unbounded creation within finite limits is the essence of what we humans do.
That’s why I now talk about software cultivation.
What do you think?
Inspired by
‘s post.
Kent Beck, Tidy First? A Personal Exercise in Empirical Software Design, p. 70