Describing the Problem

  • I'm seeing [symptom] when I [action] — it only happens in [condition].
    Structured bug description
    "I'm seeing a 500 error when I submit the form — it only happens when the email field is empty."
  • Expected behaviour: [X]. Actual behaviour: [Y].
    Classic bug report framing
    "Expected: the save button is disabled when the form is invalid. Actual: it's clickable and throws an unhandled exception."
  • I've narrowed it down to [area] — everything upstream looks clean.
    Reporting progress before asking for help
    "I've narrowed it down to the serialisation layer — everything upstream looks clean."
  • Here's the stack trace — the error originates in [method].
    Sharing a stack trace with navigation
    "Here's the stack trace — the error originates in UserService.findById() at line 47."

Thinking Out Loud

  • My hypothesis is [X] — let me verify by [test].
    Narrating your debugging hypothesis
    "My hypothesis is that the cache key is colliding — let me verify by disabling the cache and retesting."
  • Does this only reproduce in [environment] or everywhere?
    Scoping the reproduction
    "Does this only reproduce in production or can you replicate it locally?"
  • Can you rubber-duck this with me for a minute?
    Asking for a sounding board (rubber duck debugging)
    "I've been staring at this for an hour — can you rubber-duck this with me for a minute?"
  • What changed recently in this area of the codebase?
    Asking about recent changes as a debugging lead
    "What changed recently in this area? The bug appeared this morning after the deploy."
  • Let me add some logging here and check what's actually being passed.
    Proposing an instrumentation step
    "Let me add some logging here and check what's actually being passed to the function."

Phrases to Avoid

These common phrasings undermine your professionalism. Here are better alternatives.

Avoid "It's broken and I don't know why."
Better "I'm seeing [symptom]. I've tried [approaches]. My current hypothesis is [X]."

"I don't know why" is a dead end. Documenting what you've already tried and your current hypothesis gives collaborators a starting point.

Avoid "It works on my machine."
Better "It reproduces on my local environment but not in CI — here are the differences in config I've found so far."

"Works on my machine" without follow-up is a conversation stopper. Documenting environment differences moves the investigation forward.

Avoid "The code is wrong."
Better "This function returns [X] when I expect [Y] — let me trace through the logic."

"The code is wrong" assigns blame without insight. Stating the specific discrepancy leads directly to the fix.

Practice Exercises

Choose the most professional or correct phrase for each scenario.

Frequently Asked Questions

What is a "stack trace"?

A stack trace is a report of the active method calls at the point an exception occurred. It shows the chain of function calls that led to the error, helping you pinpoint where in the code it happened.

What does "reproduce" mean in debugging?

"Reproduce" means to trigger the bug consistently using a defined set of steps. A reproducible bug is much easier to fix than one that appears randomly.

What is a "null pointer exception"?

A null pointer (or null reference) exception occurs when code tries to access a method or property on an object that is null — i.e. the variable holds no reference to an object.