The debugging method
Keep the failure check stable while experiments shrink the uncertainty.
Predict first
Before you read: predict
A catalog preview shows the wrong title. The team can read the saved title, patch the renderer as the likelier cause, or capture another screenshot.
Which next step can separate a stored-data explanation from a rendering explanation?
The 30-second version
Debugging is a controlled experiment loop. Reproduce the failure, remove irrelevant parts, and write a hypothesis with an observation that could refute it. Choose a cheap discriminating observation before changing several conditions. Fix the cause, rerun the same reproduction and keep a regression guard. A green check proves little if you changed what success means. S1
Keep the failure check stable while experiments shrink the uncertainty.
How it works
Step 1 of 6
Analogy: An arborist investigating a leaf-blight complaint
In this imagined investigation, the arborist first records the affected leaves and growing conditions. Repeating the observation under those conditions gives a shared record. Changing several treatments at once might hide the marks, but would make it harder to explain which condition mattered. A useful check has outcomes that change the next investigation step.
| Arborist investigation | Debugging loop |
|---|---|
| Repeat the reported condition | Reproduction |
| Remove irrelevant circumstances | Minimise |
| Predict what a check would show | Hypothesis |
| Repeat the original check after a change | Verify the fix |
The analogy concerns diagnosis, not tree care or safety. Software experiments need an explicit expected result because a visible symptom can disappear while the underlying requirement is still broken. Reducing the case means keeping the relevant failure, not making the example small at any cost. A different failure after removal is also not automatically the same reproduction. S2
Separate observations from explanations in the investigation notes. An observation describes what happened under recorded conditions; a hypothesis proposes why. A successful prediction raises confidence but does not make alternative explanations impossible. Write down a result that would count against the proposal, then actually allow that result to change your view. Otherwise a long sequence of experiments can become repeated confirmation of a favourite story. S3
Cheapness is contextual. A local observation that separates the known alternatives is preferable to a more expensive action with the same information, given equal safety and reliability. The opening scenario states that comparison explicitly. This is not permission to run risky production experiments because they are quick. Production incident containment and operational safeguards are covered elsewhere. S1
Try it
Answer first, then check. Nothing is saved.
Question 1 of 4
The import ['A','B','A','C'] produced validator code E17.
Which compact artifact belongs in the incident record?
Question 2 of 4
The hypothesis is: every mispriced catalog result requires a cache hit. A test can independently record whether a hit occurred and whether the price is wrong.
Which observation contradicts that stated necessity?
Question 3 of 4
Price badges show NaN for some products. The investigation shows that the importer stores those prices as comma-decimal strings such as '12,50'; the badge computes Number(price), and the cart total reads the same stored price.
Which change should the repair make?
Question 4 of 4
A fee calculator previously rounds a 19-cent subtotal down. A repair changes that branch.
Which automated check is a useful guard for that defect?
Go deeper
Pro tip
Keep a short investigation log of observations, attempted experiments and their results. It helps avoid repeating a failed approach and makes the reasoning available to the next developer. Google SRE, Effective Troubleshooting, read 2026-09-29. This is an operational habit, not another assessment option.
Checked against the tools and docs as of 2026-09-29.