Debugging means investigating, not guessing

The default reaction to a bug is to change something and see if the error goes away. This works for trivial problems and creates chaos for real ones. You end up with three changes stacked on top of each other, the original error is gone, but now there are two new ones and you can't tell which change caused what.

Stop. Read the error message. Form a theory about what's wrong. Find evidence that supports or contradicts your theory. Only then make a change, and change exactly one thing.

I had a deploy that looked fine according to every automated check but showed a blank page to visitors. Instead of changing code randomly, I took a screenshot of the live page (blank), checked the page source (content was there), and realized the animations were hiding everything until the user scrolled. The fix was targeted because the diagnosis was correct.

When you hit a bug, resist the urge to change code immediately. Instead:

1. Reproduce the bug. Can you make it happen consistently? 2. Read the error. What is it actually saying? 3. Form a theory. What do you think caused this? 4. Find evidence. Check logs, inspect the page, trace the data flow. 5. Fix one thing. The thing your evidence points to. 6. Verify. Does the fix work? Did it break anything else?

Every bug that survives the first obvious fix attempt. If changing one thing didn't work, stop guessing and start investigating.