Keep it short and clear, the secret to a great Developer Checklist
Errors in programming can be disastrous.
My computer science professor relayed a story about telecommunications. A developer forgot the semicolon on his program. Because of this, it brought down the phone system.
Medical errors can be deadly.
In 2009 Atul Gawande published The Checklist Manifesto. As a surgeon, he wanted to curtail medical errors.
He shares many tales of people who die or are hurt because of medical errors. Gawande writes about how professionals deal with complex responsibilities.
Checklist Manifesto
He shares how we need to categorize our errors. First, we have errors of ignorance. Essentially, we don’t know enough information.
The second type is errors of ineptitude. In this type, we don’t use the information we do know. This is the focus of his book.
Common mistakes
For surgeons’ there are common mistakes. Developers have them as well. What are some of yours?
Steve McConnell points out in his book Code Complete. “We need to learn the types of mistakes we make.” As a Java developer, I have made some mistakes repeatedly.
Early in my career, I would need to remember to initialize my variables. After a few issues, I created a checklist to review.
Brainstorm issues
Bring the team in on this. Brainstorm common issues. Perhaps there are a few typical defects. What can be done to fix them?
Scrum teams could add the checklist to their definition of ready and definition of done.
For instance, a few teams I have worked with pulled in incomplete stories. The velocity of the team suffered as a result.
Higher Standard
Establish a higher standard of work. For Gawande, he wanted to raise the level of medical care.
As developers, we can raise the level of quality. We can reduce random errors by checking common issues.
Short and clear
Create your checklist to be short, clear, and focused on the essentials. Make it easy to do.
Long and wordy ones won’t be used. As well as could also be confusing.
Did I create a unit test? Yes, that was easy.
Did I create a unit test that covers all paths of execution, including checking for unused objects? The first time you are rushed you will pass on doing this.
Create with the team
I mentioned before to include the team in your checklist. This can be a wonderful collaborative affair.
You could gather the developers and get their input. They may have things they check as well.
Similarly, if you include the Quality Assurance team they will know your tendencies. Tom forgets to check out-of-state users. Add them to your list.
Revisit often
Don’t create a developer checklist and never update it. Keep tinkering with it.
As I mentioned before I created one when I was a beginner Java developer. Now, as I learn Vue.js I have other items I focus on.
So keep adding and taking items off your list. Keep it short and succinct. Long lists are hardly used.