One difference between hospitals and programming is that code is entirely digital, so a lot of check lists can be replaced with automated tests. For example:
Instead of “did you run the code to make sure it works?”, have test cases. This is traditional test cases. (Fully end-to-end testing is very hard though, to the point that it can be more feasible to do some QA testing instead of trying to automate all testing.)
Instead of “did you click the links you added in the documentation to make sure they work?”, have a test that errors on broken links. Bonus is that if the docs link to an external page, and that link breaks a month later, you’ll find out.
Instead of “did you try running the sample code in the library documentation?”, have a test that runs all code blocks in docs. (Rust does this by default.)
Instead of “did you do any of these known dangerous things in the code?”, have a “linting” step that looks for the dangerous patterns and warns you off of them (with a way to disable in cases where it’s needed).
Of course not everything can be automated (most of Gunnar’s list sounds like it can’t). But when it can be, it’s nice to not even have to use a checklist.
One difference between hospitals and programming is that code is entirely digital, so a lot of check lists can be replaced with automated tests. For example:
Instead of “did you run the code to make sure it works?”, have test cases. This is traditional test cases. (Fully end-to-end testing is very hard though, to the point that it can be more feasible to do some QA testing instead of trying to automate all testing.)
Instead of “did you click the links you added in the documentation to make sure they work?”, have a test that errors on broken links. Bonus is that if the docs link to an external page, and that link breaks a month later, you’ll find out.
Instead of “did you try running the sample code in the library documentation?”, have a test that runs all code blocks in docs. (Rust does this by default.)
Instead of “did you do any of these known dangerous things in the code?”, have a “linting” step that looks for the dangerous patterns and warns you off of them (with a way to disable in cases where it’s needed).
Of course not everything can be automated (most of Gunnar’s list sounds like it can’t). But when it can be, it’s nice to not even have to use a checklist.
Our code review checklist looks like this:
Have GDPR annotations been added for all fields? (all fields that are stored persistently count)
Do interactions with the user happen that should be recorded as events?
Is data collected for later use (logging doesn’t count, anything in a database does)? Are there reports or some other way to find this data?
Are there no unencrypted credentials in any files?
Are there notable changes that should be recorded in an ADR?
(I replaced the links with public alternatives)