A not-so-simple question
Dear software makers,
What are we?
Are we hackers, who, in the words of Richard Stallman, explore âthe limits of what is possible, in a spirit of playful cleverness?â
Are we craftsmen, who, in the words of the Software Craftsmanship Manifesto, âare raising the bar of professional software development by practicing it and helping others learn the craft?â
Are we ninjas, jedis, gurus, or rock stars?
Stereotypes and Caricatures
Personally, I wouldnât want any of these titles, and Iâm troubled that anyone would want to glamorize what we do with terms like rock star. I certainly donât see anyone here where I work wearing leather pants and thrusting their hips toward a screaming audience (nor would I want to!).
Iâm somewhat fond of a caricature I grew up with, which was something like a pedantic, bearded, and pony-tailed dungeon master, similar to Comic Book Guy in The Simpsonsâââbut thatâs not something I see around either. Itâs a stereotype, probably an old one, and it probably never reflected the truth.
What exactly, then, defines those who make software?
Doing Rather Than Being
My experience is that the most defining characteristic of software creators is that weâre doers who want to solve real problems. Why create a wrench when thereâs no bolt to turn? Why assemble the bolts and brackets and other parts, if the result doesnât make life better for someone?
A practical outcome, thatâs what weâre after.
Every day that I go to work, I want to write code that has a result. It could be calculating a statistic, delivering a message, booking a trip, paying a bill, or any one of a million things. But the essence of building software âthe purpose, the motivation, the heart of itâis in the end goal. Without a final outcome, the activity of making software would cease to have any meaning. It would be the most dissatisfying experience in the world.
What if weâre âengineers?â
Now, in my opinion, thatâs the definition of an engineer. Henry Petroski, a professor of civil engineering at Duke University, has said, âscience is about knowing, engineering is about doing.â What better description could there be of the heart and blood pumping through the software engineer than that?
Doers are engineers.
Science is about knowing, engineering is about doing. ~Henry Petroski
Engineers are doers, with a caveat
Engineers are doers, but with an important distinction. Weâre not designers and weâre not mad scientists. Weâre not, for example, the crackpot scientist Doc Brown from Back to the Future who is always running around imperiling space-time.
As fun as Doc Brown is to watch, we wouldnât want to be known as dangerous people.
But, to get real world results from software, we do have to know something about the real world and thatâs also embedded in the idea of engineering. Often, what we need to know to accomplish some task is knowledge thatâs already available, if it would only be applied.
In other words, the fastest and best way to achieve a result is to take whatâs there and put it in action.
How it all goes wrong
The flip side is also true. Disregarding existing knowledge often results in disaster. A building constructed without sound engineering practices collapses to the ground.
So as we work on the problems in front of us, we likely have a dozen real-world considerations flooding in at any moment, threatening to derail our efforts. Our only comfort will be that weâre aware of them and mitigate their impact.
Take a normal, everyday business example: crunching some statistics for the visits to a website over the dayâs âpeak hoursâ of 5am to 7pm. To even select the right data in the first place, we have to have knowledge of which time zone (UTC) and time format (ISO-8601) the database uses.
Even then, our effort may be thwarted entirely by a simple oversight. Although the times in the database are in UTC, âpeak hoursâ happen in pacific time, which means they vary depending on whether its daylight savings time or not. When pacific daylight time is in observation, peak hours fall across one range in UTC (12pm to 2am) and across another (1pm to 3am) when pacific standard time is in observation. Weâd need to take into account which time zone is actually in effect for the day in question, if we want to be correct.
Knowing the body of knowledge thatâs been gathered about the real world and then applying it through software, is therefore key to doing anything with software. This is why I have one burning message for programmers right now:
Put the engineering back in software engineering
What I mean is: become familiar with any science or mathematics that impacts your particular software domain. Not just computer science! Know any relevant statistics, physics, biology, meteorology, chemistry, geology, or psychology. Keep references near at hand. Make no assumptions and donât pioneer your own path where good paths already exist.
Know and follow standards. Seek out the tried and the true. The physicist and mathematician Freeman Dyson once said,
A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.
These two guiding principles: knowing accepted science and applying already-existing, stable solutions wherever possible, will allow us to do more good for the world.