Troubleshooting–Beware the Inattentional Blindness

The last post (and first podcast) on You’re not so smart blog caught my attention and reminded something I’ve seen and experienced personally when doing most kinds of troubleshooting sessions (bugs, performance issues, security audits,…).

Did you saw it?

If you didn’t see the video, here it is, give it a try(even if you saw the original one or read the book).

So, how does all this relate to troubleshooting?Well, It’s true the video/study targets particularly our visual perception, but I would say it can be much more powerful that just visual perception.

Back to troubleshooting…

When we are searching for a specific thing/cause we usually miss all kinds of information. Note that our brains actually do that for all kinds of good & practical reasons, it’s just that it can also severely impair our troubleshooting workflow & accuracy.

Generally, and when troubleshooting, I would say to postpone any hunches or possible causes for a specific problem as long as you can. Focus on collecting useful  information first, do not think, do not analyze, be a passive observer… be as curious as you can but aside from that do not be the first to… “shoot”.

When you finally go for some  solutions/causes, then be aware that you will be more susceptible to miss, filter information or even distorting it to make it “fit” to your thinking.

We usually don’t like being wrong too, and our ego can also further disrupt further relevant information processing. We also, again… usually :), don’t like to be the root cause of the spotted issue/problem/bug… we will resist to that, the “certainly, it was not me” syndrome.

Final thoughts

So, what does this mean for for software developers, testers, and many other related roles? Well… some thoughts:

• know your stuff, but accept  that problems usually don’t choose technologies or fields just because you’re particularly skilled at them
• first, gather all the information you can, be a passive observer, go for a diverse baseline of data/information
• having that, then start diagnosing, putting the pieces together
• when searching for something specific, try to keep perspective & all possibilities open, know a little bit how your brain usually works, your biases (confirmation,inattentional Blindness)
• let your ego out of it, it’s not personal
• and (particularly for software developers) please learn to properly read stacktraces! :)

I think there’s a reason for Edgar Poe’s Dupin, Agatha Christie’s Poirot or Conan Doyle’s Sherlock Holmes to usually only reveal the puzzle solution right near the end of the story. It’s not that they waited until the end… it’s that they focused on gathering information, then putting the pieces together, not the other way around.

Further reading

• Inattentional Blindness
• Confirmation Bias
• The Texas Sharpshooter Fallacy
• The Sunk Cost Fallacy
• Occam’s Razor (It is a principle urging one to select among competing hypotheses that which makes the fewest assumptions and thereby offers the simplest explanation of the effect.)
• Hickam’s dictum (“Patients can have as many diseases as they damn well please”. )

 

PS-What do you hear?

What about another amazing ride on the power of our brain reality twisting skills? Hear for yourself!

 

 

Now…back to this annoying “bug”… :)

Regards,

Rui