Optimistic skepticism

I've been deep into updating two separate test stations recently, and I almost repeated a mistake I made last fall: wanting the code to work so much that I willingly believed that a bug had just one source.  Fortunately I dug deeper and found three separate sources of a single bad result.

For a couple of years in the late 90s I tested software for HP/Agilent.  When you test software, the goal is to break it.   You go to your job thinking, "What would a user of this software do that the programmer would not expect to happen, and will that behavior break the program?"  It was a difficult gear change at first, but I think it made me a better programmer (that's the reason that many young  programmers at Microsoft get their start testing code).

A primary goal of a programmer is to get his code to work.  There's an indescribable, almost physical thrill you get when an algorithm you've invested so much time into comes together and performs.  To subsequently try to break it is a literal buzzkill.  

Test engineers, at least the ones who also write code for their systems, are sometimes stuck between opposing priorities.  On the one hand, you enjoy building a new system that works.  On the other, the system has to work all the time - the worst result from a test system is erroneous data that you think is correct - so you have to spend a good deal of time trying to break it.  

It's a tough row to hoe, but that's just part of the job.