one of my motivations for writing this debugging zine is that I've seen "USE THE SCIENTIFIC METHOD" as an explanation of how to debug a million times and -- while obviously that explanation works for a lot of people and that's great -- it's never been helpful to me.
"come up with a hypothesis, test it, repeat" is so rigid and what actual scientists do is so much more complicated!
does anyone else feel this way?
(please do not try to explain the scientific method to me :))
As a couple of people in the replies have said: "come up with a hypothesis you can check" is important for debugging but there are SO many steps before "I have a hypothesis" that it skips over.
To get to a reasonable hypothesis, you need to print things out, read the docs, try a debugger, reread the error message, look for suspicious recent commits, comb through the logs, read some code, talk to a rubber duck, and so much more
It's not the hypothesis for what the problem is, but a sequence of hypotheses that you try to quickly refute. For example, first hypothesis that people usually try to confirm/refute is "there is an actual problem". There are many times afterwards when you do indeed try to look for leads, but:
- they are interspersed with hypothesis testing (it's not that hypothesis testing is concentrated at the end),
- IMO doing prep work to make them shorter/fewer is one of the more useful kinds of prep work, because they rely in some way on luck.
So I agree that it makes sense to concentrate on non-hypothesis-testing parts in any advice disproportionately to the time they should usually take, because they can be helped more by working out patterns to follow compared to the hypothesis-testing parts.
