I like debugging as much and possibly more than I like programming.

I have been programming computers for over 56 years. I can be that precise because I first put my hands on a computer on Super Bowl Sunday #1.

In all those years, I think successfully debugging software has given me more pleasure than writing software.

As will come as little surprise, I adore detective or whodunit novels. However, somewhat contradictorily I dislike solving puzzles because solving a set puzzle seems pointless compared to debugging software, and thereby making it work.

There is also an extraordinary phenomenon in programming that all programmers have experienced. It happens like this:

1) You discover there is a bug in your program, and you enlist another person to help you debug it.

2) In order to do so you need to explain to them what the program does.

3) As you recount what the program does, you stop because you realize that program actually does some different that you just told the person it did.

4) You thank that person for their time, and you run off to fix the problem you just discovered.

This is remarkably like the concept of the "abstract other" described in psychotherapy. As you externalize your thoughts by talking to another person, in fact, any OTHER person then it allows you to see the problem or issue from a perspective outside of your own. I will leave any reference to Rabbie Burns for others to make.

This aspect of programming resembles an aspect of writing when you think you have a wonderful idea, but as you try to write it own it just comes apart at the seams and dissolves into nothing.

One should never forget that a bug really is just a disagreement about how a program is expected to work versus how it does work. That is why you can often declare some behavior to be a "feature" as opposed to a "bug" or perhaps you use "anomaly" to describe it rather using the dreaded "bug" word.

In many cases you cab "fix" a bug by changing the documentation rather than the code. Given that a bug or anomaly is a mismatch between a person's expectations about what the program should do and what the program actually does, then you change the person's expectations by changing the documentation while leaving the program unchanged.

Sometimes the documentation just says, "Don't do that" As an example of that approach, I will tell you that I found a "bug" in the arithmetic operation of Division because Dividing by zero does not work! Oh? I am not supposed to do that, and I should not ask why because that is just how Division works? So basically, this is an error in my understanding of Division rather that a flaw in Division? Wow! I wish I could push my problems off on others as Division has done so with me.

My final comment about errors in software come from a friend of mine who switched from designing system software to designing hardware instead. I asked him why he switched from software to hardware. He said that when he thought about how many inadequacies of the hardware he had to deal with when he wrote system software, he decided that he would rather make errors that the software developers would fix rather than have to fix the errors that the hardware designers had made. So he switched from software to hardware.

He obviously learned the fundamental lesson of Division. if you hardwire and build it into the operation then you just tell people that this is how it works, and that' final.

As a database designer friend of mine was fond of saying. "When do you play a crooked wheel? When it is the only game in town"

Some bugs you just live with.