Skepticism and Cynicism may not seem like opposites, but in the world of debugging, they often are. As discussed yesterday, the Cynical Debugger says "I believe that things can and will go wrong, and I want to plan for that." Balancing that attitutde, the Skeptical Debugger says "I don't believe that bug report" and "There's probably a much simpler explanation". An expert debugger knows how to manage the tension between wanting to accept the crazy things that happen to an application in the wild, and wanting to dismiss bad or highly improbable data.
When a bug report is submitted to me, one of the first questions I like to ask myself is: what of this information, if any, seems totally out of line? As described in this post about saying 'no' to a bug report, an application can't be all things to all people, and it is necessary to say 'no' at times. Reading the report with a cynical eye will give you plenty of reasons to say 'yes', but reading the report with a skeptical eye will tell you why you can say 'no'. It is what prevents you both from catering to the whims of particular users, and from embarking on a wild goose chase for a bug that occurs under questionable circumstances. Take for example a bug report like this:
"I was testing the latest build of the client software, and when I sent a login request to the server it spit out a stack trace back at me. Please fix the server."
It's quite possible that the latest build of the client software uncovered some bug in the login procedures on the server. But it seems much more likely that the thing that changed, i.e. the client software, is to blame and is now doing the login procedure incorrectly. Spending a lot of time investigating this "server" bug is very likely going to result in simply figuring out what the client is doing wrong and then telling them about it. Unfortunately, people often want to blame the component that is producing the error and not think about what has changed. With a skeptical eye, you can step back and ask "why is this bug happening now?", and try to communicate that you are not absolving the server of responsibility, you are simply skeptical that a properly functioning server that has not been changed would suddenly fail.
The same goes for bug reports that look like, "My computer has been acting flaky all day, and your application keeps crashing. Please fix your application." Users want something to blame, and if you have a reputation as a responsive team that can fix things in a hurry, these kinds of bug reports will only increase. The key is again, remaining skeptical, and communicating your skepticism to others. "I'm guessing that your computer acting flaky is the cause of the application crashing, and not the other way around. You normally don't have any problems with our application, and your computer has acted flaky many times in the past, right?" These kinds of skeptical statements help clarify that you are open to fixing real problems with your and even others' applications, but you are not all-powerful.
Distance Debugging is ultimately about figuring out where to apply your limited resources in a highly uncertain environment. Being appropriately skeptical can help you avoid getting trapped into expending these resources in inappropriate, counterproductive ways while still letting your team and your users understand that you will invest the necessary resources when the situation warrants.