A hypothesis about software excellence

3 min read Original article ↗

When looking for a software engineering position, I ask a question during interviews that gives me great insight into what I care about at a company: "During the average week, what are you mired in?"

Answers range from "meetings" to "Docker containers." "Meetings" is not the worst answer, but I want to know what the meetings are about. The worst answer is people mired in the complexity of their infrastructure.

I'm not an infrastructure person. I'm not into the latest deployment platforms or CI/CD automation tools. Those things are essential, but I want to set them up and forget them. The deployment apparatus should be simple, so it frees our time for business value.

I'm looking for people engaged in the ideas that form the basis of the business. They don't have to have it figured out. But they need to actively search for the fundamental concepts and good representations of them. That is the experience I've had working at the best jobs I've been in.

At the worst jobs, infrastructure was king. The technical leadership loved new deployment tech, new AWS services, Docker command-line switches, and message queues (oh, so many queues!) Our jobs became duct-taping these bits together to get something to happen. Somebody else told us what that something was. We became experts in the infrastructure, and the business team managed the ideas.

At the best jobs, yes, there was infrastructure, but we kept things simple to explore the business concept space. We became experts in the domain, often understanding it more deeply than the business teams. At a document signing company I worked for, I learned all about the history of contract law. At the e-commerce company I worked for, I learned about retail and how stores set prices. What I learned informed how I wrote the software.

All of this is purely anecdotal and based on personal experience, but there may be something measurable and actionable there. The State of DevOps Report extrapolated the DORA metrics from survey data. Could we develop a survey that asked a similar question to mine? It could go something like this:

How much of your time, in percentages, is devoted to the following activities:

  • Managing infrastructure

  • Adding features

  • Modifying existing features

  • Fixing bugs

  • Exploring business domain concepts

Someone who knows how to do qualitative research could come up with a better question. However, I hypothesize that the time spent exploring business domain concepts correlates with software excellence. If we find that it doesn’t matter, then I’ll know it’s just my personal preference. But if it does matter, then we’ll have a clue about how we can better spend our time.

Discussion about this post

Ready for more?