When the train comes, everybody rides!

The other day, I mentioned rubber duck debugging, a term with which I had been previously unfamiliar. Since then, I have wanted to pick up a rubber duck to keep on my desk at work, to help me to work through the more difficult issues I encounter (and because it's just funny to have a rubber duck on your desk).

I finally found one the other day. The only problem was that..well, there wasn't "a" rubber duck...apparently they come in flocks or something...

So yes, I bought the whole kit and caboodle. Walking out of the store, I said to my wife that now I had to find a bunch of people who wanted rubber ducks, since there were 16 in the package, and my issues are 1-duck, maybe 2-duck problems at worst. She thought for a second, and suggested "Maybe your blog readers would like the extras?". Brilliant!

So here's the deal. I bought a pack of 16 ducks:



The four large ones have been spoken for, so that leaves 12 little ducks. Since I'm guessing more than 12 people will want a duck, I'm going to have to give them out randomly. To help with this, I've created a 4 question survey. 2 real questions, along with your name and email address, so I can contact you if you win a duck. Please know that I will absolutely not give, sell, or relinquish-under-torture your email address. I'll just use it to contact you if my random number generator tells me you that you get a duck.

I'm leaving the survey open all week, since I know not everyone has time to read every day, and I've been way too busy to post normally anyway.

By the way, you don't pay shipping or anything. It's a real, honest to God giveaway. Enter the survey, win a duck, and I'll throw it in a (probably USPS, if you're in the states) envelope and ship it to you.

Note: I make no claims about the troubleshooting prowess of these ducks.

Pre-emptive Troubleshooting

Troubleshooting is a very reactive process. By its nature, you're fixing an already existing problem. As good as it is to be able to troubleshoot, it's better to prevent weird problems from cropping up in the first place.

As sysadmins, we have numerous ways to do this. First, as Michael Jenke very sensibly suggests, is to use structured systems management, by administering via script instead of editing files by hand, or worse yet, clicking through the interface.

Another very potent tool that Chris Siebenmann brings up today is using checklists to perform complex tasks. (Incidentally, Chris mentions a term I've never heard before..."rubber duck debugging". I think I'm going to try to expense one of these for troubleshooting purposes)

I'm a firm believer in checklists for anything that isn't (or can't be) automated. On our internal wiki, I have checklists for things like adding and removing users from the infrastructure, adding new machines, etc etc. They're great, and I don't have to "remember" everything that needs done, I can just do it and it's always accurate. And if I've left something off the list, I add it to the list, and it's more accurate.

I wasn't always such a checklist person. It took a while for their usefulness to sink in. Tom Limoncelli does a great job of explaining why in his blog post, Transforming an art into a science, where he explains that back in the bad old days, planes kept crashing until pilots started pre-takeoff checklists. Similarly, Boston.com has an article about doctors using checklists, which resulted in 36% fewer complications and deaths in the operating room.

Checklists take complex, fun tasks and make them boring.