3 ms·
This talk, "Debugging with the Scientific Method" changed how I debug problems. I try to watch it once every year or two. tl;dr, when debugging people natural
by seanc 4y ago
This talk, "Debugging with the Scientific Method" changed how I debug problems. I try to watch it once every year or two.
tl;dr, when debugging people naturally form a hypothesis about what is going wrong and then set about gathering evidence to support or refute that hypothesis. When you do so unconciously you are very prone to biases of all sorts, most importantly confirmation bias.
When you do so mindfully, and Write It All Down then you are much more likely to a) come up with an evidence gathering exercise which will usefully falsify your hypothesis, and b) respect the gathered evidence, reject the now false hypothesis, and move on to a new one.
https://www.youtube.com/watch?v=FihU5JxmnBg https://www.youtube.com/watch?v=FihU5JxmnBg
- tootie 4y agoOne thing I have learned is to never say "This should work". If it doesn't work it shouldn't work.
- seanc 4y agoFor sure! My least favourite type of bug is the converse though. "How is this possibly working?" When you're pulling on a thread and come across a function that looks completely broken and yet somehow is not.
- snarfy 4y agoThe biases are probably the biggest road block. You make an assumption of what is wrong and start looking in the relevant code. There thousands of if statements that all start somewhere at the top ,creating a big fork. It's easy to get stuck when you are looking on the right side when the issue is on the left. Always understand that your assumptions can be wrong.