Here was the question:
"How do I fix a really difficult bug in programming?"
Here was my first answer:
There is no such thing as a “difficult bug.”
I suspect my answer requires further explanation. First of all, I doubt that you have experienced actual bugs in your computer, the kind with 8 legs that bite and swarm. I have, a couple of times, but they are rare, and usually not difficult to eradicate.
Perhaps you are talking about errors, but using inaccurate language. In that case, I will assert “there is no such thing as a difficult error.” The same error might be handled easily by a different person. I have seen that circumstance often. For instance, I once spent a month trying to pinpoint a coding error. When I finally asked the help of a colleague, she found it in less than two minutes.
No, there are no difficult errors, but there are people who have difficulty with an error. We have all been there, and we tend to want to blame the error rather than ourselves.
So, the first thing you need to do to handle a “difficult bug” is to ask yourself,
“What is it about me that is making this error so difficult to handle?”
Perhaps you are having difficulty because you are impatient, or think failure to handle the error will make you look bad to your boss or colleagues.
Perhaps pressure to handle the error is throwing you off your center, distorting your thinking.
Perhaps you do not know enough about the system with the error, or the language in which the program is written.
Perhaps your mind is on other things in your life, things distracting you because they are more important to you than this darn “bug.”
Maybe you should discuss this error with a colleague or two, What is it about you that is keeping you from doing that?
Anyway, good luck in your quest for resolution.
Take a look at Errors: Bugs, Boo-Boos, and Blunders
Two cases in my experience are the tough ones, at least mentally.
ReplyDelete1. The hardest bugs to find are those that don't exist.
Let's take a simple program I write from scratch. It has absolutely no bugs or errors. Wait a second! It has no bugs? That can't be.
So now I spend an extra hour or two to discover there really are no bugs. Had I found a bug or two, I'd likely have been satisfied earlier.
This has only happened a few times but I feel better when I find errors I created, it means I know it better. It's up to you to decide whether the extra time was wasted or not.
2. When there are dependencies on external data, networks or systems.
For the end user, I feel their frustration getting some generic error message that is cryptic at best and may have nothing to do with the cause. In any case, you have to rely on processes and people you can't control.