A hypothesis about software excellence
Does time spent exploring business domain ideas correlate with good software?
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.
Straight forward, this is what I'm doing currently. But its slow, wondering if there is a shortcut to knowing the right questions to ask at a job interview. In your post your hinting at some things I think are signs of businesses that have certain issues.
Much appriciated!! .. Personally, I'd love to know your thoughts on essential questions / the thought procces behind comming up with the right questions (on an individual basis) to ask an employer in a job interview. To help us know what we getting ourselves into. And making sure the match is right before starting the job.