February 09, 2009, 12:05 PM — From time to time, my long suffering wife asks me what the heck I do all day and where all the techie problems that furrow my brow to a depth of 0.5 inches come from? It is a really good question and recently I have been expending some energies trying to figure it out.
I am at the early stages of thinking it through but it is already pretty clear to me that:
0 - I like solving problems
1 - there are good techie problems and there are bad techie problems
2 - it is really, really important to differentiate between the two problem types
3 - most techies do not make the differentiation
To understand item 0 above, a further observation from my wife is in order. She knows now, through years of observing the furrowed brow, that it is often replaced by a grin and a giggle and a general "a ha!" type metamorphosis in my facial expression.
Why do I work with computers? Because they provide an endless supply of interesting problems. Problems that need to be solved by what we call "debugging". Problems that drive me nuts but that with perseverance, mostly yield to solution. I am a problem junky. I seek out bugs and I seek to destroy them with a mixture of analysis, tools and experience. It is fun!
I have Debuggers Delight Syndrome. Debugging can be incredibly frustrating but we techies do it in glorious anticipation of the fun bit at end when we have finally figured it out. We let ourselves grin a bit, share the wonders of it with colleagues. Then we move on to the next problem. Repeat ad infinitum.
The "fun" bit here is the nub of the issue. From a pure problem solving perspective the origin of the problem is irrelevant. It is simply a problem. Problems need solving. We go to it. We chase the high that a solution will bring. We often do not worry about why the problem exists in the first place.
Case in point. For years I was a C, C++ programmer and I surrounded myself with debugging tools an techniques and lore in order to debug the often bizarre problems that can result with this sort of low level language. Boy was it fun! The thrill of the chase, zooming in on problem areas, setting traps for the recalcitrant software to fall into, lying in wait for conditions to be just right...Those where the days.
I remember when it finally dawned on my that I was getting too much fun out of the debugging process and loosing sight of what I needed to achieve at a business level. I was processing big volumes of text at the time. Why oh why was I messing around with bugs in my pointer arithmetic when I should have been focusing on the outputs my customers needed?
I switched to dynamically typed languages with good native text processing capabilities (firstly Perl,then Python) and haven't looked back. I still spend all day every day bashing my head against interesting problems but now, I'm getting my kicks out of problems that are inherent to the business problem - not inherent in the technology stack. I still have Debuggers Delight syndrome. It is genetic I think. The big difference between the me that debugs problems today and the me that debugged problems 20 years ago is that I see a greater understanding of where best to focus my debugging efforts.
And you know what? I now have an extra level of interesting problems to solve. Namely, how to differentiate between problems I need to focus on and those I do not need to focus on.
It is a very interesting problem and one I delight in trying to solve.
