When trying to find a bug, forget what you expected or wanted, and focus on what your program is doing. Holding onto the specs while trying to find the bug just slows you down.
I notice when I use this approach, I feel less frustrated. Instead of “this isn’t working!!!”, I feel like a detective, learner, or explorer.
P. S.
(I picked this approach up from poking around Stanford’s programming methodologies course (CS106A). The exact document I found it in is here.)
(I’m always happy to hear about exceptions and nuances regarding rules/approaches/mindsets, and so I invite Devil’s advocates to reply. One way I can think of this rule going wrong, especially for Fast.ai Part I, is trying to figure out what one’s program is doing in too much detail. This rule doesn’t say which level of analysis to choose when doing the task of: “focus on what your program is doing”.)
Usually a bug comes from an assumption you’re making that a) isn’t true, and b) sometimes you don’t even know about.
If you look at your code and you think, “this looks correct, why doesn’t it work?” then what your brain thinks the program is doing is actually different from what you’ve written, or the data it works on / API it talks to isn’t what you think it is.
A program can make complete sense in your mind but not work, which means that your mind is misleading you. The only way to find out what’s going wrong is to check that each part of the program really is doing what you think it is.
I’m an experienced programmer so it usually doesn’t take me long to find what is causing a bug, but when it does take long it’s always because I’m trying too hard to hold on to an assumption that I haven’t validated.
I find it frustrating that very often the code one writes in a notebook is not the cause of an error. I encounter errors that originate in OS (Windows usually) or the libraries I installed are old or (sometime newer). Can you suggest a good resource to learn debugging technique from?