• Read the FULL error message, not just the first line.
• Read the FULL stack trace. Identify the frame in YOUR code (skip framework internals).
• Note the exact input / request / action that triggered the bug.
• Note the expected behavior vs. the actual behavior.
• Check logs (application logs, server logs, browser console).
• Note the environment (OS, runtime version, dependency versions, config).
• Check if the bug is reproducible. If not, note the frequency and conditions.

"The crash occurs because

user.profile

is null when the user has not completed onboarding, and line 47 accesses

user.profile.name

without a null check."

"Something is wrong with the user object."

• The hypothesis must explain ALL observed symptoms.
• If it only explains some symptoms, it is incomplete — keep refining.
• Generate multiple competing hypotheses and rank by likelihood.

• "If the null profile hypothesis is correct, then logging

  user.profile

  on line 45 will print

  null

  for users created after January 1."
• "If the race condition hypothesis is correct, then adding a 500ms delay before the second call will make the bug disappear."

• Change ONE thing at a time. Multiple changes make it impossible to attribute cause.
• Revert experiments that did not help. Do not accumulate random changes.
• Use version control: commit or stash working state before experimenting.

• If the prediction matched, you have likely found the cause. Write a fix and a regression test.
• If the prediction did not match, your hypothesis was wrong. Return to Step 2 with new information.

1. Identify the entry point and the crash / wrong output point.
2. Add a log or assertion at the MIDPOINT of the code path.
3. Is the state correct at the midpoint?
   • YES -> The bug is in the second half. Move your probe to the 75% point.
   • NO -> The bug is in the first half. Move your probe to the 25% point.
4. Repeat until you have isolated the exact line or function.

1. Take the failing input dataset.
2. Remove half the data.
3. Does the bug still occur?
   • YES -> The bug is in the remaining half, or is independent of the removed data.
   • NO -> The trigger is in the removed half. Restore it and remove the other half.
4. Repeat until you find the minimum failing input.

Error: Cannot read properties of null (reading 'name')     <-- Error type + message
    at getUserName (src/services/user.js:47:22)             <-- YOUR CODE (start here)
    at handleRequest (src/routes/profile.js:12:15)          <-- Caller
    at Layer.handle (node_modules/express/lib/router.js:5)  <-- Framework (skip)
    at next (node_modules/express/lib/router.js:13)         <-- Framework (skip)

1. Read the error message at the top.
2. Scan DOWN the trace to find the FIRST frame in YOUR code.
3. Open that file at that line. This is your starting point.
4. Read the frames above and below for context on the call chain.

• Symptoms: Missing first/last element; array index out of bounds; fence-post errors.
• Check: Loop bounds (

  <

  vs

  <=

  ), array indices (0-based vs 1-based), string slicing (inclusive vs exclusive end).

• Symptoms:

  NullPointerException

  ,

  Cannot read properties of undefined

  .
• Check: Optional chaining, uninitialized variables, missing return statements, database queries returning no rows.

• Symptoms: Works sometimes but not always; fails under load; test flakiness.
• Check: Shared mutable state, async operations without await, missing locks/mutexes, event ordering assumptions.
• Diagnostic: Add delays (

  sleep(500)

  ) to amplify timing windows. If the bug becomes more or less frequent, it is a race.

• Symptoms: Correct behavior initially, then gradually wrong; restart fixes it.
• Check: Global/shared state, caches, singletons, mutable default arguments, in-place mutations of objects passed by reference.

• Symptoms: Slow degradation over time; eventual crash; "too many open files."
• Check: Unclosed file handles, database connections, HTTP connections, event listeners not removed, intervals not cleared.

• Symptoms: Garbled text, wrong characters, parsing failures.
• Check: UTF-8 vs Latin-1, JSON/XML escaping, URL encoding, base64 padding, line endings (CRLF vs LF).

• Symptoms: Works on one machine but not another; works locally but not in CI/production.
• Check: Environment variables, file paths, dependency versions, OS differences, timezone, locale.

• Read the assertion message. What was expected vs. actual?
• Is the test itself correct? (Tests can have bugs too.)
• Is the test isolated? Run it alone. Does it pass?
• Are test fixtures up to date?
• Did a recent change to shared code break this test?

• Read the full stack trace.
• Reproduce it with the simplest possible input.
• Check the exact line. What variable is null/wrong?
• Trace the variable backward. Where was it set?
• Is there a missing validation or null check?

• Confirm the expected output is actually correct.
• Add logging at the input and output of the function.
• Binary search: where does the data go wrong?
• Check type coercion (string "1" vs integer 1).
• Check operator precedence and short-circuit evaluation.

• Profile first, do not guess. Use a profiler tool.
• Identify the hottest function or query.
• Check for N+1 queries, unnecessary loops, missing indexes.
• Check for memory leaks (heap snapshots over time).
• Check for blocking I/O on the main thread.

• Run the test 100 times in a loop. What is the failure rate?
• Check for race conditions (add delays to amplify).
• Check for dependency on external state (clock, network, filesystem).
• Check for test pollution (shared state between tests).
• Check for non-deterministic inputs (random, timestamps, UUIDs).

• [timestamp] Bug reported by [who/what]
• [timestamp] Reproduced in [environment]
• [timestamp] Root cause identified
• [timestamp] Fix deployed

• Added regression test: [link]
• Added monitoring/alerting: [details]
• Updated documentation: [link]
• Other: [details]

1. Remove unrelated code paths.
2. Hardcode inputs instead of reading from files/databases.
3. Replace external services with stubs.
4. Reduce data to the smallest set that triggers the bug.

1. Find the last known working state (commit, release, date).
2. Diff the code between then and now.
3. Read each change. Could it cause the symptom?
4. Use

   git bisect

   for large ranges.

1. Comment out half the suspicious code.
2. Does the bug persist?
   • YES -> It is in the uncommented half.
   • NO -> It is in the commented half.
3. Repeat until isolated.

1. Reproduce first. If you cannot reproduce it, you cannot verify your fix.
2. One change at a time. Multiple changes destroy your ability to reason about cause and effect.
3. Read before you write. Spend more time reading code and logs than writing fixes.
4. Trust nothing. Verify your assumptions. Print the value. Check the type. Read the documentation.
5. The bug is in your code. It is almost never the compiler, the OS, or the framework. Check your code first.
6. Write the regression test. A bug without a test is a bug that will return.