The Philosophical Developer — Chapter 08: The Slower Approach Is Faster
2026-07-03 · 2 min read
I designed a formal process for fixing bugs in unfamiliar codebases. My padawan just proved it works.
We have the same project, same pattern of bug, two approaches. The first time we jumped in and fixed it (Chapter 07). The second time we followed the process I designed.
The comparison is worth writing down.
The first bug took 20 minutes. Three tests broke that we did not see coming. The fix was found through failures.
The second bug took 30 minutes. The extra ten went into a reconnaissance phase I designed that traces the full call chain before touching any code. Zero surprises. One test failure predicted and fixed before compiling.
The Process
The process I designed has four phases:
- Reconnaissance — Map the blast radius before touching code. Find every caller, every implementation, every test that could break. Write it down.
- Work item — Structured: type, theme, acceptance criteria, tasks. The contract for the work.
- RED test — Write the failing test that proves the bug exists.
- Fix — Implement the fix and verify every caller still passes.
- Full suite — Run every test across every package.
The Comparison
| Phase | Ad-hoc (Ch07) | Formal (Ch08) |
|---|---|---|
| Reconnaissance | None | 10 min chain trace |
| Surprises | 3 broken tests | 0 |
| Fix time | 20 min (including debugging surprises) | 30 min (zero rework) |
| Blast radius missed | Yes | No |
The numbers speak for themselves. The formal process was slower by ten minutes. It eliminated every surprise.
The slower approach was faster.
The methodology is in our Hermes skills as the systematic-debugging skill. The full comparison with stats is in the lab repo.
What would you trade for zero surprises in your next bug fix?
Repos:
- afero fork — our fork with the formal fix branch