How to keep a debugging log that actually helps
debugging journal, tracking hypotheses, time-boxing, rubber duck debugging, documentation of findings
Why You Need a Debugging Log
Memory is lossy. After 45 minutes of debugging, you will forget which hypotheses you already tested. A debugging log prevents you from looping back to ideas you already disproved and gives you something to share when asking for help.
What to Record
Use a plain text file or a scratch pad. Record: the symptom exactly as observed, each hypothesis you form (one line each), what test you ran, and the result. Mark each hypothesis as CONFIRMED, REJECTED, or PENDING. When a hypothesis is rejected, note why -- that reasoning will save you time later.
## Bug: Order total wrong for coupon codes
## Symptom: total shows 120 instead of 80 for 20% off a $100 order
H1: Coupon not applied -- REJECTED (coupon object present in cart state)
H2: Discount calculated on wrong base -- REJECTED (base price is correct: 100)
H3: Percentage parsed as string, concatenating not subtracting
Test: console.log(typeof cart.discount) outputs string
Result: CONFIRMED -- parseFloat() missing on coupon value
Fix: parseFloat(cart.discount) before arithmetic
Time-Boxing and Rubber Ducking
Set a timer. If you have not confirmed a hypothesis in 25 minutes, explain the bug out loud to an inanimate object -- or write it in your log as if explaining to a colleague. The act of articulating the problem forces your brain to restructure what it knows, and solutions surface. If 45 minutes pass with no progress, ask another human. Debugging in isolation indefinitely is not productivity.