Several times in the discussions here I read about the checklist in question: but these are obvious items, why do they need to be checked? I think that is the v

Several times in the discussions here I read about the checklist in question: but these are obvious items, why do they need to be checked? I think that is the very point of check lists: not to miss actions, because they seem to be trivial/obvious. Be it because the stress levels are high or because one is focussed on the "real problem at hand". In a sense, the more intelligent/capable/experienced you are, the more you are at risk of missing something as you are focussed on the big picture. As a software developer, while not having checklists as printable documents, I highly appreciate the checklist approach. This can take several shapes. When doing a software release, I perform the necessary steps always in the same order. This makes it easier to correctly perform everything needed. And of course I check the result of every step for the expected result. Checklist-like approaches can be even very helpful when debugging issues. I often enough get to resolve "the software doesn't work" like issues. And of course, there is no obvious reason, like a meaningful error message or stack trace. To debug this kind of issues, I start with simple and trivial things. While not a static list - the cases are too varying for that - I tend to start with asking and checking very basic questions, like: is there enough free disk space? Repeating the steps which, according to the bug reporter, lead to the issue. At each action taken, verify that any observeable result matches the expectation, even if those actions are not close to the bug. This approach has usually two outcomes. Either a very trivial explanation for the problem is found, because some seemingly trivial step fails, or at least, I know, that all the things tested are note related to the problem. Excluding a wide range of possible problems can be surprisingly helpful in narrowing down the actual problem.