Debugging

The epistemological structure of a piece of software and a scientific theory is the same: you can’t “prove” a theory is correct in the same way you can’t “prove” a piece of software has no bugs, but you can do lots and lots of testing
The logical parallel clarifies (IMO in an interesting way) a fact of scientific research that I didn’t understand for a long time: you need expertise/peer review to evaluate scientific studies. This is for the same reason that programmers need domain-specific experience to know whether a given piece of software is “well-tested” or not. “Well-tested”, as a criteria, is defined relative to other, similar software and to standard practices in that field. This is why “facts guy” is often wrong: they don’t know what works, so they don’t know if a given experiment is rigorous.
When you have any kind of non-trivial bug in your software, you have two problems: (1) the software is broken and (2) your mental model is broken (i.e. you don’t know why the bug is happening because you don’t know what the software is doing). It’s sort of impossible to fix (1) without fixing (2), so my debugging technique focuses on fixing (2).
Fixing broken mental models is the purpose of the scientific method, and it really works great for debugging. I just keep a Google Doc, and I use my mental model to make guesses about what the software is doing (but not necessarily about the root cause of the bug; just anywhere I think I might be wrong about anything).
Once I have a hypothesis about what the software is doing, I literally write out “Hypothesis”, “Experiment”, “Result” in my Google Doc. I think of one or more experiments to test the Hypothesis, write them down, do them, and record their results.
“Result” always starts with “disproves hypothesis” or “consistent with hypothesis” (again, you can’t ‘prove’ a hypothesis is true. But you’re testing it, and “consistent with” means the hypothesis passed this test, so it’s not wrong yet). I color-code the “Hypothesis-Experiment-Result” block red or gray if the hypothesis is disproven, and green if it’s not.
This technique parallelizes well: if lots of people are working on a bug, each person can do an experiment in parallel. Similarly, if a manager wants to see progress in investigating a bug, this list of hypotheses and experiments is a good way to show that.