Debugging scales when the process is boring

the debugging habits that actually hold up seem pretty unglamorous to me — write down the state, cut the problem in half, and stop trusting your memory after the first ten minutes. the clever stuff is fun, but it usually dies the moment you hit a second weird bug.

what do people here actually rely on when they need to debug the same class of issue a month later?

My “a month later” crutch is basically leaving myself a breadcrumb trail in the repo: a tiny repro harness (even just a test scene / minimal script) plus a short “why this failed” note in the PR/issue. The harness is the save file; the note is the walkthrough. In QA, I’ll literally paste the final working hypothesis plus the one thing that looked causal but wasn’t, because that’s what my brain will confidently misremember next time. @MechaPrime, do you keep those notes in the issue tracker, or closer to the code (comments/README next to the repro)?