One Big Problem
When I help family and friends with computer problems that get thorny, they often apologize for making me frustrated or causing trouble. The thing is, even if we have to try a large number of things that don’t work, these problems are usually straightforward compared to the ones I deal with at my job every day. Even more than that, I usually don’t see those problems as frustrating; sure, if I get stuck for five hours and it turns out to be something stupid I should have known the answer to from the beginning, that’s annoying, but most problems I deal with don’t belong in that category. Mostly, they’re just part of the task.
Enterprise software and systems development – the five-second version of what I do at work – is largely the art of making things work together that were never designed to work together, don’t want to work together, come from completely different manufacturers and eras, but ultimately really need to work together unless you want to replace everything you’ve spent millions of dollars on over the last thirty years at the drop of a hat to add one new tool. (Oh, and your users also don’t know and don’t tell you what they actually want from the new system, but they still want you to deliver exactly what they need early and under budget.) Typically these disparate systems are patched together with little snippets of code, toothpicks, and duct tape; the joins are often not documented except for in the head of someone who left the company twenty years ago; and there are numerous hidden gotchas that everyone has to relearn every time someone new works on the system. And then each of the components can have its own problems and its own challenges when writing and changing the code. Even when the components are largely well-designed – as, thankfully, most of the systems I work on are – the only amazing thing is that anything works at all.
To me, this environment means that my entire job is one big problem. I show up in the morning, check my email, maybe fix a few things for people, then move into working on my most important project. The project is probably stuck at some problem I’m trying to solve, so I start by working on that problem. Once that problem is resolved, I take the next steps, which probably go another few minutes until I run into another problem, and then I’m working on that problem. And so on (except in reality, there are long pauses while waiting for someone or something to be available to help solve one of the problems or take one of the intermediate steps).
That sounds exhausting, and sometimes it is, but if you think about it the right way, it can actually make the problems less frustrating. Because running into many problems is inevitable on any project (if you have any doubts as to why, just look a couple paragraphs above at my description of a typical enterprise software architecture), I don’t see them as irritating obstacles but rather as an essential part of the task of making a change or integrating a new product. If there weren’t problems, there would be nothing to design and build and I wouldn’t have a job, and if I somehow did have the job, it wouldn’t be a meaningful one requiring skill or even any human intervention at all.
Other kinds of projects may not regularly run into so many problems, but this mindset has something to offer to non-software projects nevertheless. And if any project involving design or invention or novelty isn’t running into at least some problems (or challenges or failures or bugs or whatever you might want to call the form they take in that project), I’d venture to say the project isn’t doing anything worthwhile. So if you need a sound bite, it’s this: problems aren’t interlopers that show up unexpectedly to throw off your project, they’re a normal part of the work that makes up the project, and finding them and solving them doesn’t need to be aggravating.
For curious readers, there was no Control-Alt-Backspace post last week because my internet access was out for four days while I would normally have been researching and publishing the post! (It was actually kind of nice… but I’m glad to be back in the 21st century now.) The normal posting schedule will continue from here through the 16th; after that I will be off for the following two weeks, until the first week of 2020, for the Christmas holidays.
