systematic-debugginglisted

# Systematic Debugging Most failed debugging is not a reasoning failure — it is skipping straight to a fix that plausibly explains the symptom, watching the symptom move, and calling it solved. This is the loop that makes that impossible, and it is deliberately slower at the start and much faster at the end. ## The loop 1. **Reproduce it deterministically.** A bug you cannot trigger on demand cannot be proven fixed — every later step is guesswork. If it reproduces only sometimes, that intermittency *is* the first finding: race, ordering, uninitialized state, environment. 2. **Capture the actual evidence.** The real error, the real stack, the real values. Not your recollection of them, and not what the code says should happen. 3. **State one hypothesis** that explains **all** the evidence. If it explains only part, it is wrong or incomplete — say so rather than proceeding. 4. **Design the cheapest experiment that could REFUTE it.** This is the step that separates debugging from guessing. Looking for confirmation finds it every time; a hypothesis that survives an honest attempt to kill it is worth acting on. Same discipline the `challenger` applies to an elected oracle. 5. **Narrow.** Bisect the input, the commit range, the call path — halve the space each time rather than re-reading code hoping to spot it. 6. **Fix the cause, not the symptom.** If you cannot say *why* the fix works, you have not found the cause; you have found something that pertu