On problems

I like the soft popping noise a problem makes when it gives up its mystery. It's like the  interlocking ring puzzles that come the better class of cracker. You sit on the sofa full of Christmas surrounded by adults comparing holidays with these mysteriously entwined rings, turning them and trying to squeeze one through the impossible diameter of the other until a distaff twist ... and they're separated in your lap.

I wish that programming were full of problems like this: in truth they're the exception. Coding problems fall into three categories, of which these are the nicest, best rounded. They're the Miss Marple mystery of coding problems: it had to be the Vicar, because only he could have had access to the greenhouse's poison cupboard and knew that Anaconda venom was poisonous because of his time in Peru!

The second category is the "well, I can kind of see how you get from here to there" problem. This is the majority of coding work. You know roughly what the solution will look like, but you don't know if the answer is right until you've built half of it. And by the time you've built half of it, the end is nearer so, even though it's not the best route, you carry on coding until you're halfway there again, and you can stick your head up over the maze and realise the end point is a bit over there now, so you code in that direction, and so on (at risk of ending up on a Zeno's paradox project.)

It takes a brave developer to admit that the last half-effort took them slightly off course, especially when management sees that you're making progress. We called the last one Miss Marple: this is more like plodding police procedural - you get there in the end, but it's a slog.

The last category of problem is usually reserved for bug-fixing. Instead of the problem yielding to an elegant solution (Miss Marple) or simply getting less problematic with effort (Procedural), the problem actually gets worse as you look at it. This is usually symptomatic that you (or more likely the cockeyed bastards who put your legacy code together before your time) have accrued Eurozone levels of technical debt. No solution exists without making the problem worse for the next person to come across the code. Because of the complexity of the plotting, and the jaundiced view of your fellow man that wading through brittle type hierarchies and circular dependencies can induce, I'll name this the James Ellroy category of problems.

Over my career I think I've spent about half my time doing Procedurals and very nearly the other half doing Ellroys. The Marple problems have been few and far between. Perhaps if I worked in a language where the ratio of thought to code was higher (Haskell, say) more problems would dissolve into elegant compositions of Marples. But it's the Procedurals that pay the rent, and the Ellroys that build up system knowledge.