Sometimes that’s what I would like to say to people dropping me an email or hooking me up on GTalk past midnight with some tricky framework-specific problem. But I don’t! Because I’m a nice guy ;o) And I have nothing against you guys, quite the opposite actually because I always learn a lot in the process, and the next time someone asks me the same question, I can pop the answer out of my hat like a magician and I love that.But because I’m such a nice guy, I’m just going to reveal a little piece of my secret for you. When you can’t find the source of an error intuitively or magically, there is a standard procedure that every call center guy in India knows about: troubleshooting. It can be a somewhat long process but it’s so simple that it can be… very fast. Here are the basic steps:

  1. Identify symptoms: not what happens, but how it manifests to you, what is the exact exception stack trace, what are the red lights on. And don’t try to interpret and filter out symptoms that you don’t think are important, or symptoms you don’t want to be important. Try to be objective and factual.
  2. List potential sources: try a google search based on your observations in step 1, try to guess based on your experience and knowledge, understand the process at work and what it involves, including all of its steps. And once again, don’t filter out some of them because you think they’re not important. Once you figure out what was going wrong, it’s always surprising to see how far it was from what you expected in the first place. And then try to order them by order of likelyhood.
  3. Proceed by elimination: take the first one in your list and figure out a way to eliminate this potential source, do some basic testing out of your specific context, isolate this source and test your problem against it. And do that for every element in your list until there is only one you can’t eliminate. And if it comes down to more than one option, then at least you have reduced your field of investigation and you can ask more precise questions to Google or people you know.

And once you’ve got the source, then congratulations, you’re almost done! All that’s left is to find a solution.

This process is so simple and so common that most people think it’s ridiculous. Look, take any user manual around you and you’ll find a troubleshooting section that leads you through that same process. Even psychologists sometimes use that approach to help you in finding a solution to your problem, I’ve seen it in coaching myself. So okay, it’s gonna take some time, but you know what they say: it’s not about the destination, it’s about the path to get there. And you’ll see that after a few times using that simple process, you’ll be far more efficient AND independent with it. And then people can drop you an email or hook you up on GTalk past midnight and ask you a cumbersome question, and you will help them eliminate a first potential source, post an rant on your blog, and go to bed hoping that the source list won’t be too long ;o)

Categories: Geek Culture


Sebastien Plisson · October 4, 2007 at 5:58 pm

Hello Sebastien,

Sorry for Gtalking you past midnight… ;-)

I realize that I become too lazy and when I m stuck with a problem wit hAndromda, I rely too rapidly on your skills and ask for help instead of applying the process you describe and that of course I know. Not so long ago, I practiced it a lot but you know when pressure is getting higher on delay, etc…
Thank you for your talent !
See you

Sébastien · October 6, 2007 at 1:10 am

As I said: no big deal.

Occam's Razor Debugging | Wavyx · October 6, 2007 at 12:53 am

[…] a right way to handle the “Debugging process” (as some project manager could call it) : Do It Yourselft!. And I must confess I quite agree with these ideas (quite is to make sure I can switch my beliefs […]

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.