Posted just now about writer’s checklists – so let’s post about the developer’s checklists here too!

As a developer, I maintained a checklist of troubleshooting tips.

I would have conversations like this:

Me: Any thoughts on what I could do next?

Colleague: Have you tried [something they also recommended last time]?

Me, embarrassed: Uh… no. I’ll try that. Writing that down this time! Thanks.

And I’d add that to my checklist.

For reasons unknown, developers assume that we are the last person in our organization who will ever encounter a specific problem.

• We’re the last person our team will ever onboard, so we don’t need to document lessons learned during onboarding.
• This error message won’t happen again, so there’s no need to note the steps we took to address it.
• Nobody else will install or configure this product, so we won’t bother writing down the process we went through.

And then we’re surprised when three days or weeks or months later, the same situation has come up again and we’re struggling to remember what we did last time.

Last page list

I kept my troubleshooting checklist starting on the back page of my notebook so I could always find it in a hurry.

The specific items on the checklist will vary from person to person, but they might include:

• When did this code work last? Did it ever work?
• What changed between when it last worked and now?
• Can I reproduce the problem in another environment? How about another branch of my code?
• What if I back out my last change?
• Have I tried clearing the browser cache? (Ugh. I always forget.)
• Did I push the change to the environment where I’m expecting it?
• Am I getting an error? Search for the exact text of the error in the code, in Slack, on the web…

Keep adding to it as you learn more!