Flying, Checklists, and Updating Poker Copilot
Years ago I flew from Mt Gambier, a town of 25,000, to Melbourne on a 14-seat plane. I was the last to board, so I had to take the only seat left – the copilot’s seat. Best. Flight. Ever. You haven’t flown until you’ve had the cockpit view the entire flight.
Two things still stand out today about the flight:
- At one stage I rested my long legs on what I thought was a footrest. It wasn’t. The pilot asked me politely to take my feet off the co-pilot’s flight pedals.
- The pilot had many checklists. Before taking off, the pilot went through a long checklist, checking off each item as he performed what was listed. After take-off, he went through another checklist. Before landing and after landing, he went through two more checklists.
This checklist approach fascinated me. The pilot didn’t rely on memory to do things right. He was required to specifically perform a series of steps, in a certain order, and indicate that he had performed each step.
My first few Poker Copilot releases were a haphazard affair. To put some order into the release process, I followed the flight industry’s example and made a checklist. Each time I make a new release I follow the list. The list is often changing. Sometimes I find a step is missing and I add it. Sometimes I realise that I can automate a step.
It helps.
Question: Can’t you automate everything?
Answer: Nah. One of my steps is to search for and destroy all print statements in my code, left over from debugging. Another is to do a smoke-test on Tiger, which involves rebooting my computer from another partition. Yet another is to announce the release on my blog. And so on. These things are best done manually, I think.