What speedrunning Resident Evil 4 taught me about debugging

Outside of work I speedrun Resident Evil 4. From the outside it looks like a reflex hobby. From the inside it's mostly a measurement discipline with a survival horror theme, and it has changed how I debug software more than any book on debugging did.

Splits are profiling

A speedrun timer doesn't show one number. It shows splits: your time through each segment against your best, so you know exactly where a run gained or lost.

  speedrun splits                      request trace
  ---------------------                ----------------------
  village    12:41  -0:03              auth check        4ms
  castle     31:07  +0:12  <-- here    db query        212ms  <-- here
  island     18:22  -0:01              serialization     9ms
  ---------------------                ----------------------
  you don't guess where the            same idea, worse
  time went. the timer says.           lighting.

Nobody who runs games would "optimize" a segment without splits, yet I watch engineers (myself included, on bad days) optimize code they never profiled. The feeling of where time goes is wrong constantly, in the run and in the request.

Routing comes before execution

Runners don't start by playing fast. They start by planning the route: which items to grab, which fights to skip, where the route spends time to save more later. Execution is the last step, after the plan survives contact with the whole game.

Debugging works the same way when it works at all. The tempting move is to jump straight to the code you suspect and start changing things. The route move is to trace the actual path first: what called what, with which inputs, in which environment. Reading before typing. Every debugging session I've regretted started with an edit instead of a trace.

Resets are the iteration loop

A fact that surprises non-runners: a serious attempt ends in a reset within minutes, most of the time. Bad spawn, missed trigger, reset. The whole practice is built on the loop being cheap. Load, attempt, learn, again.

The debugging equivalent is reproduction cost. If confirming your fix takes a 20-minute deploy or clicking through nine screens, you will test fewer hypotheses per hour and hold more speculation in your head between attempts. When I hit a bug like that now, I fix the loop before the bug:

1. Get the failure into something that runs in seconds. A test, a script, a curl command.
2. Only then start forming theories.

Shortening the loop feels like a detour. It's the fastest part of the route.

RNG manipulation is deterministic testing

Enemies in RE4 have random elements, and runners hate randomness, so they manipulate it. Position, timing, and inputs get standardized until the "random" behavior collapses into something that happens the same way every attempt.

That's flaky test remediation. A flaky test is RNG you haven't manipulated yet: a real race, an order dependency, a shared bit of state. The runner's instinct applies directly. Don't retry until it passes. Pin down every input until the behavior has no room to vary, and if it still varies, you've found the actual bug.

Consistency beats hero strats

Every category has a faster, riskier strategy someone lands once in ten attempts, and a slower one that works nine times in ten. Runs are won with the second kind, because a route is only as fast as your ability to finish it.

I hold fixes to the same standard. The clever patch that works when the stars align loses to the boring change that works every time, survives review, and can be explained in one sentence.

The game is deterministic underneath, and so is the program. When either one misbehaves at random, the randomness is always an input I haven't found yet.