Find the cause of a bug by halving the search space instead of guessing — bisect the timeline, the input, the code path, and the environment. Use when debugging, when a bug is hard to locate, or when something used to work.
---
name: debug-by-bisection
category: coding
description: >-
Find the cause of a bug by halving the search space instead of guessing —
bisect the timeline, the input, the code path, and the environment. Use when
debugging, when a bug is hard to locate, or when something used to work.
---
# Debug by Bisection
Guessing scales badly. Each guess tests one hypothesis out of hundreds, and a
wrong guess teaches you almost nothing. Bisection halves the remaining
possibilities every time, so twenty candidates take five steps and a thousand
take ten.
The method is always the same: **find something you can cut in half, cut it, and
determine which half still contains the problem.**
## Step 0 — Get a reliable reproduction
Nothing below works without this. You need a command or click-path that produces
the bug **every time**, and a clear statement of what "broken" means.
If it only fails sometimes, make it reliable first:
- Run it in a loop until you can quantify the rate ("fails ~1 in 20").
- Remove sources of variation — fixed seed, fixed clock, single thread, one
worker instead of four.
- If the rate changes when you add logging or slow it down, you are probably
looking at a race.
An intermittent bug that you "fixed" without a reliable reproduction is a bug
you have not fixed.You are reading the opening of this skill.
The rest is open to any signed-in account — free included. Reading the library costs nothing.
Shared publicly by the author and open for any use. See the Terms.