There’s a general guideline in software development that states you should always work at the highest level of abstraction you can, so that as much of your time is spent as possible “living in the problem domain.” I wanted to look at how this could be applied in life as well as software.
In Software
“Live in the Problem Domain” is a jargon-y way of saying that if you’re writing an e-commerce web app, for example, you want to be thinking about customers and products and orders, not reading bytes from a disk and parsing HTML and constructing TCP packets and the like.
This guideline is why software engineers love “frameworks” so much. You have a server-side framework like ASP.NET to handle the nitty-gritty details of working with HTTP connections. You have a client-side framework like jQuery or Kendo UI or Angular to handle reacting appropriately to user input when you’re in the browser.
That’s all well and good. These frameworks make you more productive as a developer because you’re not spending huge amounts of your time writing a bunch of code to do low-level things that has already been written a million times before. You stand on the shoulders of giants by letting well tested libraries handle the stuff that every application needs to do so you can focus on just the things that are unique to the specific problem you’re trying to solve.
In Life
If this principle of “living in the problem domain” works so well for developing software, I thought, how can I apply it to my career in general?
For me, this meant switching jobs. Writing software is the only real career I’ve ever wanted, the only answer I’ve ever had for “what do you want to be when you grow up” after I accepted that “baseball playing astronaut” wasn’t a realistic option. At both of my previous “real” jobs in software development I functioned as an internal consultant to a larger organization. I supported dozens of individual software applications for various other departments throughout the organization.
This seems to be a very common method of structuring software development for organizations that are not actually in the business of creating software. They have a small team of developers who are farmed out to all the various other groups as needed, those groups then pay for the developers’ time when they want some work done.
The problem with that model is that rather than spending time in the “problem domain” of developing software, for which I was hired and went to college, I was spending most of my time juggling dozens of projects and customers and was unable to actually focus on any one project long enough to spend a meaningful amount of time doing the thing I was hired to do. It also means that often, the only option was to do everything in as quick-and-dirty a method as possible, because the customer can only pay for a single-digit number of hours of work, and you know you’re going to get pulled off of that project momentarily and be asked to work on something else.
It’s like asking a juggler to re-paint all the bowling pins he’s juggling and also carve a few more without ever dropping any of the ones he’s currenty got in the air. And that juggler never went to school for juggling, he’s actually a trained bowling pin carver, and would really rather just focus on that part of the operation and leave the whole juggling mess to somebody else.
Software as the Product
Contrasting that model to my current situation, where I work at a company whose only product is the software I am helping to create, is a night and day difference. There is a single application that a whole team is helping to develop, rather than each developer having a dozen or more applications they support pretty much on their own. Granted, the application is much larger and more complex than any of the applications I supported in my previous jobs, but the majority of my day is spent thinking about software development, rather than on organizational and administrative issues.
I don’t think I would ever go back to a consultancy or sub-contracting type position. You spend too much of your time working on problems that have nothing to do with developing software. All of the biggest challenges in my previous jobs weren’t “how do we make our product(s) better,” or “how do we implement feature x,” they were “how do we keep our group functioning because we have way too many things to support.” You inevitably build up a huge backlog of technical debt when you work in that fashion because you never have time to do anything the “right” way. There’s too much overhead and too many projects to spend time setting up niceties like Continuous Integration and automated testing and actually ensuring quality in the software you create because you have hundreds of separate, small projects. You spend all your time thinking about things that aren’t really related to software development.
I had read previously about how, as a software develolper, you want to be in a “profit center,” and not a “cost center,” which is true. But going even further than that, you want to be in a position where you spend the majority of your time doing the thing you enjoy and are skilled at rather than spending your days worrying about organizational problems that you can’t control.
You want to live in the problem domain.
