[display_podcast]
One of the great things about working with diagnostic software is the great stories that for the most part go untold. I don't mean the obvious stuff about computer illiterate users trying to scan pages by holding them to computer screens, or using optical drive trays as cup holders. These are funny, but they can be found everywhere. Like airline passengers asking for window seats because they like to open the window for fresh air.
Nah. I'm talking about the good stuff. How about this one (it's real.) A computer user reported to technical support that flushing his toilet made his computer reboot. Now how would anyone figure that one out?
It turned out that this user was living in a rural area, and the water pump to the house would cause a brown-out, and that in turn would reboot the computer. Flushing the toilet would cause the water pump to turn on, and thus was a reliable mechanism for replicating the problem. Kudos to the unsung heroes of technical support for a major PC maker for figuring this one out.
Or how about the computer company that had a zero-tolerance policy for good hardware that was returned by technicians as bad. This reportedly was in response to a large portion of hardware returns by field-techs being no defect found (NDF) . Shortly after management instituted a charge-back for NDF returns, the rate dropped to near zero.
What prompted a review of the policy was the fact that the volume of parts being returned didn't change much, only now nearly all of them were truly broken. It turned out that prior to submitting �bad� hardware for return, techs would �assist� the parts to show obvious failures. I can only imagine field techs making a stop at the local 7-11 at the end of the day, and going to work on their return inventory with a stun gun.
And then, there was this (to go unnamed) audio card maker, whose card would fail our tests but pass theirs. For months the maker blamed our tests as faulty, and we checked and rechecked our code to look for what might be wrong.
Finally the PC maker in the middle trying to decide to use the cards or not was able to obtain a copy of the source code for the passing test from the audio card maker. The code was extensive, and should have done the job of testing the card very well had it not been #ifdef'd out and replaced by two print statements and a delay. Something like �print testing�, then a delay, and �print passed�.
There are more great stories, but the untold stuff is even better. These are the stories I can't tell you about (though I wish I could) unless you work for PC-Doctor. Anyway, there's the one that explains why a couple of years ago the entire PC industry went through a major hard drive crisis. Or a similar crisis relating to capacitors not much before that. Or why certain ground-breaking processors from a major manufacturer never really made it in the marketplace. Or the latest about a major software manufacturer situated in the Pacific Northwest. Or why I would never use PCs from certain makers.
But it's time to get to the point of my story. We are looking for more talent. If you have what it takes to work with us, why don't you join us. You'll also be able to hear the juicier stories that I can't tell you now, and be there to experience new ones, too.
