rseng-debugginglisted

# Debugging research software Debugging is applied science: observe, hypothesize, run the decisive experiment, repeat. The anti-pattern is its opposite - changing code until the symptom moves. Research adds two hard twists: the worst bugs produce plausible wrong numbers instead of crashes (rseng-defensive-coding exists to make them crash), and the oracle problem - when the right answer is unknown, "wrong" itself needs evidence. The discipline below is tool-agnostic; the debuggers change, the method does not. ## The loop 1. Reproduce first: a bug you cannot reproduce on demand cannot be diagnosed, only feared. Pin the environment (rseng-reproducible-environments), the data version (rseng-data-management), the seed (rseng-defensive-coding) and the exact command; record them in the issue (rseng-version-control-review). 2. Minimize: shrink input, code path and configuration until the smallest thing that still fails remains - minimization IS diagnosis (each removal that keeps the bug excludes a hypothesis), and the minimal reproducer becomes the regression test and, for dependency bugs, the upstream report. 3. Hypothesize before touching: state what would explain the evidence, predict what an experiment will show, THEN run it. One variable per experiment; write the trail down when the hunt exceeds a few steps (the notes are tomorrow's context and the postmortem's material). 4. Localize by bisection - the log-time weapon on three axes: c