A somewhat unsettling realization I had is that I have become the person you consult as an expert on things. I’ve got a pretty high “Seen It Before” index. I’ve built a lot of stuff and recovered from a lot of problems. People are interested, for better or worse, in what I have to say about how stuff ought to be developed. I keep on drawing a paycheck for this work so it seems that I’m doing it well enough.
The result of this experience is that I have recognized two very broad categories of problems that I encounter, day over day, as a professional in the world of software development.
Technical Problems
I’m using this category to hold things like algorithm design, troubleshooting software packages, or designing a software solution. This category has the stuff that really excites certain developer personalities. You get to consider things like implementation details, algorithm runtime, optimizations, technology stack choices, etc…. All of the most fun things in life reside in this category.
Over the years, I’ve racked my brain to think of what I could write that would fall into this category and actually be useful. I’ve come up short a lot, though I wrote up some tiny thing on Audit.NET (found here) a long time ago, and it seems to have been reasonably helpful to some people. The conclusion that I come to over and over again is that the world is just saturated with this kind of writing, and there are just so many people who do it better than I do. I might still do it from time to time, but it’s less interesting to me, and there is a strong inner voice that suggests I’d be better off not doing it.
That’s fine, but it’s kind of a drag if one is searching for something to write about.
Business Problems
This is the second kind of problem, and I have quite a bit more to say on it because this is where my professional life is just packed full of friction. I routinely bump up against constraints and requirements that are outside of the realm of computation. The business of software development constantly imposes a framework on you that results in compromises that you’d prefer to avoid.
I think that this is a fantastically interesting class of problems, and it’s one that software professionals all bump up against constantly. Most of us just take to the internet and complain about things in this category with our peers. I also think that my understanding of this category has been great for my career.
That’s fine, and it’s probably a great thing if one were searching for something to write about.
The Friction
When these categories interact, friction occurs.
The technically-minded developer is going to really, strenuously, aggressively prefer the opportunity to use a cutting-edge toolkit to develop a clean, well-organized solution. Timelines don’t matter; this is the reason for being alive!
The business, on the other hand, will have rough news for this developer. There is a C# solution that was written in 2002, and it drives a core part of the business, and they just discovered something in there that just has to be fixed. It’s a mess in there; good luck. Everyone who knows how to work on that mess has either been promoted out of developer positions over a decade ago or left the company.
The fact of the matter is that although your job involves writing code, your job is delivering business value. I will admit that’s an incredibly dorky-sounding term, but it’s true, and I have no choice but to deploy it. The business that uses the software you are responsible for producing doesn’t much care how well it’s architected, how robust the test coverage is, etc…. They do care about whether or not it works and puts currency in a bank account somewhere.
To the extent that this developer is able to, they should also care about that. It’s harder because this kind of friction doesn’t have a nice, mathematically clear answer. Also, because it seems to impugn the quality of the craft! It’s very satisfying to have a well-constructed project and how dare you ask otherwise?
They ask otherwise because they’d all like to continue to have jobs.
What to Do?
Real, actionable advice for this situation is easy: step outside of the immediate demands of your craft and be willing to seriously engage with this other class of problem. It’s not necessarily a fun time! It may even sound like I’ve asked you to skip dessert forever and take cod liver oil. I don’t apologize for this!
It’s necessary. Unless you’re doing academic work, whereby you’re supported by grants and university funding or whatever, the world of software is tied up tight with the world of business concerns. Things you build cannot be divorced from the concerns of getting paid, at any level.
This is the manner by which you can start to make sense of some business decisions around software development that would otherwise seem insane. It’s also the manner by which you can rationalize starting yet another side project for something to do after work. Either/or.
Joe Writes Software 