I've always loved the term "psychic debugging" as coined by non-vampire blogger Raymond Chen. It refers to user-programmer interactions in which a user complains about a situation that shouldn't be possible given the information he's given to the programmer. The result of this is the programmer has to pull a solution out of invented scenarios that appear to be reading the user's mind.

A good demonstration of this kind of psychic power can be seen on the television show House, in which patients often lie to to their doctors for various reasons, leaving the doctors to use their psychic powers to determine the possible causes of their illnesses. While House isn't about software debugging, the psychic powers used in both situations are the same. I suspect that psychic powers manifest in every type of knowledge work.

Users who need help by definition don't know enough about what they're doing to do it. If this weren't the case, they wouldn't need help. But because of the Dunning-Kruger effect users in this situation can think something is important when it really isn't, and they can think things are unimportant when they are in fact vital to determining the cause of a problem.

This is normal human psychology (which I've covered before), and I don't fault anyone for it; however, the fact that it is normal human behaviour means that it's widespread. The enduring presence of misinformation fosters the latent mind-reading powers of computer scientists, turning them into computer psychics.

(Note that these clairvoyant powers apply only to debugging. There is no mechanism that I know of that allows software developers to be able to distinguish between what people say and what they want when defining a new software application. This distinction relies more on communication skills which are much squishier than psychic debugging and isn't something that all software developers are eventually capable of doing.)

As developers are asked more questions about their software (and as developers become more familiar with the software in the case of developers brought onto applications after they've already been written) they become more familiar with problems users face. At the same time they gain deeper knowledge of the system they're working on and the external applications with which it interacts, so they have more technical knowledge to draw upon.

So when a user faces a problem ("My can of walnuts isn't opening!"), he'll try his best to come up with the scenario that's causing it. He'll tell the developer what the problem is and maybe even the steps to reproduce the problem ("When I run my popcorn popper, then get my can of walnuts, I can't open it!"). Then the developer will see this and realize that the situation the user is describing is impossible ("Popcorn has nothing to do with walnuts."), but given what he knows about the user in question and the systems he's probably using, he's able to pull a likely scenario out of thin air ("You've unplugged your can opener to plug in your popcorn popper."). If he's right, it's an astonishing feat of herculean mental strength.

When he's wrong, though, it's like those first five times in an episode of House where they misdiagnose a patient: the patient's condition declines and his family become irate. But just like on TV, screwing up gives you information you didn't have. Even though it wasn't the can opener not being plugged in, at least the developer is thinking outside of the scope that the user defined. The user might be displeased that the programmer accused him of not knowing what things need to be plugged in, but he knows more than he did before the accusation was made. At that point they both realize that it's because the popcorn popper and can opener draw too many electrons from the circuit, diminishing the usefulness of both. Stupendous!

This kind of debugging appears impressive to any party involved other than the one who holds the knowledge himself. To him, it's just the application of the details he works with on an everyday basis. As Raymond often says in his psychic debugging posts, any of his readers should be able to pull off the same tricks that he manages as long as they pay attention. Knowing how it works doesn't make his powers any less captivating.

Psychic debugging is a sign of a developer who knows the particulars of his application and all of the systems around it. Once this level of parapsychology is achieved the developer can join the ranks of Charles Xavier, Gregory House and Raymond Chen, fighting bugs and Magneto wherever they may rear their ugly, helmeted heads.