I recently read "The Checklist Manifesto" and boy was it a great read.

First it was fun to read! Checklists sound like the manifestation of boring, right? How about a story of surgeon who takes care of a minor flesh wound, when the blood pressure of the patient suddenly drops to almost zero. Cutting the patient open the surgeon finds the body filled with blood! Now if checklists are deemed appropriate for avoiding stories like this, they suddenly aren't that boring anymore, right? And the book is full with stories like this. If you imagine stories that you read visually and can't look at blood, sorry, this book isn't for you. Everybody else: Go get and read it.

Professionals of various kinds use checklists. Medical doctors, Pilots of course and many more. Yet many people claim they don't need checklists. They are smart enough to do the right things. Their job is too complicated to be pressed in simple checklists. Really? So the job of a pilot is somehow "simple"? Or that of a surgeon? Of course it isn't. But still there are many things that are actually rather simple. And it is rather difficult to not forget about those. That's when checklists help.

Since I finished the book I established two checklists for myself:

One checklist I go through every morning at work. It looks something like this (without the italics, those are just for you so you can make sense out of the few words) and is written on a post-it taped to my monitor:

• Check mail. Yes I'm proud that sometimes I'm so focused that I don't check mail at all, so I need it on my checklist
• Check calendar. To make sure I'm aware of all important appointments today
• Check logs. Of all servers, so if there is a new problem, I learn about it.
• Check Jenkins. Mail notification doesn't work, too much E-mails.
• Fill out time sheet. In the morning I remember what I did yesterday and I can enter the time I started to work.

The second checklist is for debugging problems with dependency injection. As much as I like the Springframework, from time to time it complains about being unable to instantiate a bean, because a dependency is missing, although the bean is right there in my IDE. For this I created a checklist that lists all the various possible reasons for this problem:

• What exactly is the problem described in the stacktrace. No bean of matching type? Or no bean of matching name? Or more than one bean?
• Is the bean that should get found in the correct source path I have a history of putting beans in test instead of main
• Does the bean that should get found implement the correct interface? Here it is important to check the full name
• Does it have the correct name?
• Are the scopes compatible? I'm not sure if this will actually result in the same problem

I store this one in Evernote and will pull it up when I get this kind of problem the next time.

The first checklist already proved highly useful. The second has still to be tested. I just created it when I tried to fix just that kind of problem the last time.

What checklists do you use?

One last word: Of course as software developers we have an advantage. Many things that ask for a checklist can be implement as a program. So don't replace your automatic build with a checklist please.