Weird…when you get close to something that BIG you can’t see anything at all.

-Toad the Wet Sprocket, Butterflies (Fear, 1991)

 The subject of blind spots keeps begging for my attention lately. This is when something hits me that I did not see coming or I run into something that shocks or surprises me.  Maybe this is an interaction where I feel dangerously blindsided, caught off-guard and unprepared.  Maybe this is some counter-productive behavioral pattern I did not notice as being not-so-great for me or our team.  Maybe this is a gap in my test approach. – a gap obvious to others, but not to me.  Maybe this is a more subtle metaphorical dripping faucet in the back of my mind, something I am slow to acknowledge and investigate.  My conscious quest for personal and testing blind spots started in 2010 when I attended Michael Bolton’s On Noticing presentation at my 1st CAST.

Because we are collaborating, problem solving and building great things, I think the nature of a career in software development and testing offers great opportunities for discovering blind spots  and learning from them IF we are open to having them pointed out to us through feedback or coaching or if we make time for retrospection and have them revealed to us through self-inquiry and observation.  It is important to make time to reflect on our work daily.  To jumpstart my renewed effort to do this, today I revisited these blog posts.

• Karen Johnson’s Debriefing Alone.  Question 1 is my “dripping faucet”.
• Julie Zhou’s Manager’s Manifesto

I will share several blind spot examples as part of my story in my CAST 2014 track session, Beyond Bewilderment, which is about finding personal success in testing.  Once I return from NYC, my after work time no longer dedicated to track session preparation, I plan to focus my professional development in the area of learning scripting.  This will probably lead to a post of the subject of technical blind spots through katas, paired testing and development. More later.