Debugging Playbook for Student Engineers

Most student debugging is slow for one reason: we jump from guess to guess without preserving evidence.

The fix is not "be smarter." The fix is a repeatable loop.

The loop I use

1. Define the bug in one sentence.
2. Reproduce it reliably.
3. Make one hypothesis.
4. Run one test that can falsify that hypothesis.
5. Log what happened.
6. Narrow the search space.
7. Repeat until root cause is isolated.

If you skip steps 2 and 5, you will keep rediscovering the same dead ends.

Step 1: Write the bug statement

Bad:

• "The app is broken"
• "API issue maybe?"

Better:

• "Saving a project fails with HTTP 500 only when the title contains emoji."

A good bug statement gives you conditions, scope, and expected behavior.

Step 2: Build the smallest reproduction

Your goal is not to fix the whole app yet. Your goal is to create a tiny scenario where the bug still exists.

Shrink variables:

• smaller input
• fewer services
• fewer UI actions
• fixed test data

If the bug disappears while simplifying, that is evidence, not failure.

Step 3: Hypotheses should be testable

Weak hypothesis:

• "Something is wrong with state."

Strong hypothesis:

• "The server rejects UTF-8 titles because the DB column is using a legacy encoding."

The strong version tells you exactly what to inspect next.

Step 4: Instrument before editing

Add temporary logs at boundaries:

• UI input value
• request payload
• server handler entry
• DB query parameters
• response body

In many cases, the bug becomes obvious before you change any logic.

console.log("saveProject payload", payload);
console.log("title length", payload.title.length);

Step 5: Keep an evidence log

A lightweight debugging note can be plain text:

• timestamp
• hypothesis
• test performed
• result
• next move

This prevents circular debugging, especially during stressful deadlines.

Common student traps

Editing multiple files before confirming the cause

This creates false confidence and makes rollback harder.

Copy-pasting fixes you do not understand

You might hide the symptom and keep the root cause.

Ignoring error messages because they look "too long"

The stack trace is often the map.

A quick example

Bug statement:

"Login works locally but fails in production with 401."

Fast narrowing sequence:

1. Compare request headers locally vs production.
2. Verify env vars exist in production.
3. Check cookie domain / secure flags.
4. Confirm server time skew if tokens are time-based.

This is faster than rewriting auth code.

Final rule

Debugging speed comes from disciplined elimination, not intuition alone.

Write fewer guesses. Run better tests.