My Software Development Checklists
I have not always loved checklists, but as I have come to know myself better, I've found that using them to structure my day and my work is indispensible in keeping me on track and producing excellent work.
Even when I'm feeling tired or less thoughtful or careful than I can be, I can still follow a checklist and have some guarantee that I will still do the things a previous, more awake, thoughtful, and careful version of me thought I should do, just by following the checklist.
There's no substitute for a good night's sleep, a good mental health day, and dedication to the project one is doing, but a checklist provides guard rails for those times when I just don't have those things (and they're still useful even when I am feeling my best).
We do ticket-based work (like I'm sure most of you do) in Truth Initiative Innovations, where I work as software engineer. We lay out (usually) great acceptance criteria (AC) for each feature, so we already have good guidelines for completing most tickets.
I have great teammates, and before I ever adopted the checklists I'm about to share, I once worked on a ticket for too long without referring back to the AC on the ticket often enough. Gradually the scope of the actual implementation veered away from the purpose of the ticket and into YAGNI bloat territory.
The helpful, undeserving teammate that reviewed my ticket was pretty let down at my poor work, and being the thoughtful, helpful person that they are, we started brainstorming ways I could prevent such a thing from happening again.
My solution was to create a checklist for each ticket that I start, including at minimum the AC from the original ticket text. I started using this for every ticket I implemented, and over time, I added checklist items for resolving problems like the ticket being poorly explained or defined.
I eventually added a hook to our team's workflow tool to automatically create a new copy of my checklist at the outset of every ticket I did, and I put the ticket text into that copy of the checklist. That way, I could turn the ticket test itself into a list of checkboxes, just to make sure I'd addressed everything that was asked.
Soon after, I added a similar version of the checklist specifically for reviewing others' work to force me to verify they'd addressed all the AC as well, and to help me remember to brainstorm edge cases.
These are in Markdown, but I use Boostnote for my
development notes, so the
[ ] boxes in these can be checked off as I complete
These are fluid, and I change them for every ticket I do. Usually I just change them by adding new tasks specific to the ticket I'm working on or reviewing.
Ticket Review Checklist
## Opening duties - [ ] Read the ticket title and description - [ ] Read any comments on the ticket - [ ] Ask for clarification on anything you don't understand. - [ ] Notice any discrepancies between title, description, and comments. - [ ] Clarify discrepancies with people who made ticket and did the work. - [ ] Ask ticket creator to clarify any discrepancies - [ ] Look for ticket AC - [ ] Identify ticket stakeholders/owners(s), perhaps with the ticket creator or PM - [ ] If there are no AC, work with ticket creator to define the AC: - [ ] Outline critical path for ticket (What - [ ] Embellish critical path with optional items - [ ] Obtain consensus between you and the ticket creator/owner about which items are in the critical path and which are optional - [ ] Discuss with ticket creator the importance of optional items - [ ] List risks you see for the ticket ## Testing cases Be sure to include sad and edge cases! - [ ] How could someone break this? - [ ] How could this break if a third party vendor breaks or is unreachable? - [ ] What could break that was not considered on this ticket, in the AC or by the implementer?
Ticket Work Checklist
## Opening duties - [ ] Read the ticket title and description - [ ] Notice any discrepancies - [ ] Ask ticket creator to clarify any discrepancies - [ ] Look for ticket AC - [ ] Identify ticket stakeholders/owners(s), perhaps with the ticket creator or PM - [ ] If there are no AC, work with ticket creator to define the AC: - [ ] Outline critical path for ticket (What - [ ] Embellish critical path with optional items - [ ] Obtain consensus between you and the ticket creator/owner about which items are in the critical path and which are optional - [ ] Discuss with ticket creator the importance of optional items - [ ] List risks you see for the ticket ## Questions to ask before starting work - [ ] What is the real goal of this ticket? - [ ] What does a nice internal interface look like that prioritizes maintainabity? - [ ] How will you debug problems in production? What logging do you need? - [ ] How will you analyze accuracy and performance? - [ ] What's the expected attacks on this feature? ## Work process - [ ] Write tests for AC - [ ] Generate migrations - [ ] Deploy to Heroku or staging - [ ] Move (and clean up) any comments from the ticket that should be preserved as documentation to the wiki