Don’t Panic: Fix the Problem, Not the Blame
Having spent countless hours myself on trying to fix code which just should work, browsing Stack Overflow and other online communities, it’s strange that I never stepped back to examine the process of debugging as a whole.
In today’s pages, the book mentioned the practical value of a binary “chop” (search): when debugging, cut your area of interest into half, decide which half the bug is in, and repeat until a minimal condition is found. By applying this common technique from computer science, debugging becomes much faster in larger projects.
This handy trick is one I’ll be sure to use from now on, as well as the following checklist:
“Is the problem being reported a direct result of the underlying bug, or merely a symptom?
Is the bug really in the framework you’re using? Is it in the OS? Or is it in your code?
If you explained this problem in detail to a coworker, what would you say?
If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the tests with this data?
Do the conditions that caused this bug exist anywhere else in the system? Are there other bugs still in the larval stage, just waiting to hatch?”
Thank you for reading, see you tomorrow!
#PathToSWE
