Intermediate
Debugging Language
#narration
#past-tense
Debugging Narration
6 exercises — narrate investigations using noticed → suspected → tested → found → fixed structure in standup, Slack, and pull requests.
0 / 26 completed
1 / 26
You are presenting your work in a standup. Which narrative structure is clearest for describing a debugging investigation?
Noticed → Suspected → Tested → Found → Fixed — the five-step debugging narration structure.
Each step explained:
• Noticed: what observable symptom triggered the investigation
• Suspected: initial hypothesis before any investigation
• Tested: what you did to verify or rule out your hypothesis
• Found: the root cause — what was actually wrong
• Fixed: the resolution — what change was made and why
Example:
Why this structure works:
• Listeners can follow your reasoning
• Shows you investigated rather than guessed
• Conclusion (Found/Fixed) is most important — placed last for emphasis
• Can be shortened for standup: "Noticed X, found it was Y, fixed by doing Z"
Each step explained:
• Noticed: what observable symptom triggered the investigation
• Suspected: initial hypothesis before any investigation
• Tested: what you did to verify or rule out your hypothesis
• Found: the root cause — what was actually wrong
• Fixed: the resolution — what change was made and why
Example:
"I noticed the checkout button was unresponsive on mobile (Noticed). I suspected a CSS z-index issue was blocking the tap target (Suspected). I added a pointer-events debug overlay to the element and confirmed taps were being intercepted by the overlay div (Tested). It turned out the loading spinner was positioned at z-index: 9999 and covering the entire button area even when hidden (Found). I fixed it by setting display: none on the spinner when it's not active, rather than just opacity: 0 (Fixed)."
Why this structure works:
• Listeners can follow your reasoning
• Shows you investigated rather than guessed
• Conclusion (Found/Fixed) is most important — placed last for emphasis
• Can be shortened for standup: "Noticed X, found it was Y, fixed by doing Z"
2 / 26
You are describing your investigation in a Slack message to your team. Which past tense forms are correct for debugging narration?
Option C — uses past perfect continuous ("had been seeing") and simple past correctly for completed investigations.
Past tense patterns in debugging narration:
Past perfect continuous — for patterns that happened before you investigated:
• "I had been seeing intermittent 503s since Monday"
• "The service had been consuming more memory than usual"
• "Users had been reporting timeouts for two hours"
Simple past — for discrete investigation actions:
• "I checked the logs / I added a breakpoint / I ran the profiler"
• "It turned out that…" — introducing the root cause finding
• "I found that…" / "The issue was…" / "The root cause turned out to be…"
Simple past for fix:
• "I fixed it by changing the timeout to 30s"
• "The fix was to add a retry with exponential backoff"
The phrase "It turned out that…" is essential debugging English — it introduces the finding after the investigation and signals the pivot from hypothesis to confirmed fact.
Past tense patterns in debugging narration:
Past perfect continuous — for patterns that happened before you investigated:
• "I had been seeing intermittent 503s since Monday"
• "The service had been consuming more memory than usual"
• "Users had been reporting timeouts for two hours"
Simple past — for discrete investigation actions:
• "I checked the logs / I added a breakpoint / I ran the profiler"
• "It turned out that…" — introducing the root cause finding
• "I found that…" / "The issue was…" / "The root cause turned out to be…"
Simple past for fix:
• "I fixed it by changing the timeout to 30s"
• "The fix was to add a retry with exponential backoff"
The phrase "It turned out that…" is essential debugging English — it introduces the finding after the investigation and signals the pivot from hypothesis to confirmed fact.
3 / 26
How do you correctly describe ruling out a hypothesis during debugging?
Option C — "ruled out" + evidence + pivot to next hypothesis.
Phrases for eliminating hypotheses:
• "I ruled out X" — standard investigative English for eliminating a cause
• "X was not the issue" — blunt but acceptable
• "I eliminated X as a cause" — more formal
• "X checked out / looked clean" — informal
• "X was within normal parameters" — metric-based elimination
Why adding evidence is important:
"I ruled out the database" alone is not verifiable. "Query times under 5ms throughout the incident window" gives the team confidence in your conclusion and prevents another engineer from re-investigating the same dead end.
Evidence patterns:
• "CPU was at 12% — ruling out resource exhaustion"
• "The error only appears in EU region — ruling out a global config issue"
• "Bug did not appear on the main branch — ruling out a pre-existing defect"
After ruling out, always name the next focus:
"I then focused on X" / "That led me to investigate Y instead"
This shows a systematic, logical investigation process.
Phrases for eliminating hypotheses:
• "I ruled out X" — standard investigative English for eliminating a cause
• "X was not the issue" — blunt but acceptable
• "I eliminated X as a cause" — more formal
• "X checked out / looked clean" — informal
• "X was within normal parameters" — metric-based elimination
Why adding evidence is important:
"I ruled out the database" alone is not verifiable. "Query times under 5ms throughout the incident window" gives the team confidence in your conclusion and prevents another engineer from re-investigating the same dead end.
Evidence patterns:
• "CPU was at 12% — ruling out resource exhaustion"
• "The error only appears in EU region — ruling out a global config issue"
• "Bug did not appear on the main branch — ruling out a pre-existing defect"
After ruling out, always name the next focus:
"I then focused on X" / "That led me to investigate Y instead"
This shows a systematic, logical investigation process.
4 / 26
You found the root cause. Which phrase correctly introduces it?
Option B — "It turned out that…" + precise root cause + supporting evidence.
Key phrases for introducing findings:
• "It turned out that…" — most natural; implies discovery after investigation
• "The root cause was…" — direct, formal; used in incident reports
• "I found that…" — simple and clear
• "The issue was…" — common in Slack/standup
• "It was caused by…" — emphasises causation
• "This was traced back to…" — more formal postmortem language
What makes a good root cause statement:
1. Specific component: "the connection pool" not "a pool somewhere"
2. Exact condition: "max pool size was set to 5"
3. Mechanism: "each request opened a new connection without releasing it" — explains HOW the bug occurs
4. Why it wasn't caught: (optional) "no load in staging, so pool was never saturated"
Avoid vague introductions like "probably" or "might be" when you have confirmed the root cause — they undercut confidence in the finding.
Key phrases for introducing findings:
• "It turned out that…" — most natural; implies discovery after investigation
• "The root cause was…" — direct, formal; used in incident reports
• "I found that…" — simple and clear
• "The issue was…" — common in Slack/standup
• "It was caused by…" — emphasises causation
• "This was traced back to…" — more formal postmortem language
What makes a good root cause statement:
1. Specific component: "the connection pool" not "a pool somewhere"
2. Exact condition: "max pool size was set to 5"
3. Mechanism: "each request opened a new connection without releasing it" — explains HOW the bug occurs
4. Why it wasn't caught: (optional) "no load in staging, so pool was never saturated"
Avoid vague introductions like "probably" or "might be" when you have confirmed the root cause — they undercut confidence in the finding.
5 / 26
How would you briefly narrate a complete debugging story in a single standup update?
Option C — a complete four-element story in three sentences: Symptom → Root Cause → Fix → Deployment status.
Standup debugging story template:
Example breakdown:
• Noticed: "users getting 500 errors on the payment endpoint"
• Root cause: "null check missing for the coupon code field — crashing when guest checked out without a coupon"
• Fix: "null guard"
• Status: "deployed to prod at 10:48"
Different formats by channel:
Standup (30 seconds): Symptom → Root cause → Fix → Status
Slack thread: Add one sentence on how you found it
"I noticed 500s, checked Sentry, found a null pointer on coupon_code. Added a null check — users without coupons now hit the else branch. Deployed."
Ticket comment: Full Noticed/Suspected/Tested/Found/Fixed structure with code references
Incident report: Timeline with timestamps, full root cause, contributing factors, remediation steps
The key is calibrating the depth of narrative to the audience and communication channel.
Standup debugging story template:
"[What was noticed] → [Root cause (it turned out that)] → [Fix] → [Status/deployment time]"
Example breakdown:
• Noticed: "users getting 500 errors on the payment endpoint"
• Root cause: "null check missing for the coupon code field — crashing when guest checked out without a coupon"
• Fix: "null guard"
• Status: "deployed to prod at 10:48"
Different formats by channel:
Standup (30 seconds): Symptom → Root cause → Fix → Status
Slack thread: Add one sentence on how you found it
"I noticed 500s, checked Sentry, found a null pointer on coupon_code. Added a null check — users without coupons now hit the else branch. Deployed."
Ticket comment: Full Noticed/Suspected/Tested/Found/Fixed structure with code references
Incident report: Timeline with timestamps, full root cause, contributing factors, remediation steps
The key is calibrating the depth of narrative to the audience and communication channel.
6 / 26
What is the correct way to describe a fix in a pull request description?
Option C — a PR description with Root Cause, Fix, and Regression Test sections.
PR description template for bug fixes:
Why each section matters:
• Root cause: reviewers need to understand WHY the change is correct — without this they cannot assess whether the fix is complete or if it might have side effects
• Fix: describes the logic of the change, not just the diff — "reset the counter to zero on success" explains the intent even if the reviewer doesn't read every line
• Regression test: confirms the bug cannot silently return; shows where to look if it does
Language patterns for PR descriptions:
• "Root cause: X was not doing Y when Z"
• "Fix: added / changed / removed / replaced X with Y"
• "This ensures that…" — connecting the fix to the outcome
• "Regression test in test/X.spec.ts covers the [case] path"
• "Closes #[issue number]" — linking the PR to the bug tracker
PR description template for bug fixes:
**Root cause:** [What was wrong + why it caused the observed behavior] **Fix:** [What change was made + why this resolves the root cause] **Testing:** [What tests were added or updated to prevent regression] **Notes:** [Any caveats, related issues, follow-up work needed]
Why each section matters:
• Root cause: reviewers need to understand WHY the change is correct — without this they cannot assess whether the fix is complete or if it might have side effects
• Fix: describes the logic of the change, not just the diff — "reset the counter to zero on success" explains the intent even if the reviewer doesn't read every line
• Regression test: confirms the bug cannot silently return; shows where to look if it does
Language patterns for PR descriptions:
• "Root cause: X was not doing Y when Z"
• "Fix: added / changed / removed / replaced X with Y"
• "This ensures that…" — connecting the fix to the outcome
• "Regression test in test/X.spec.ts covers the [case] path"
• "Closes #[issue number]" — linking the PR to the bug tracker
7 / 26
Sarah: 'I spent the last two hours chasing this error. I initially suspected a race condition in the database writes, but after profiling and adding logging, I realized it was actually a misconfigured caching layer that was serving stale data. It's frustrating because I wasted so much time looking at the wrong thing!'
Which of the following best describes Sarah's debugging narration, focusing on clarity for a code review?Sarah's narration demonstrates a crucial element of debugging communication: clearly outlining the initial hypothesis, the subsequent investigation stages, and ultimately, the identified root cause. The mistake here is option D; while technical language can be appropriate in some contexts, it needs to be accessible to a broader audience during a code review. Option B is correct because it highlights the key elements of a good debugging narrative – progression, detail, and clarity about what was investigated.8 / 26
John: 'I've been digging into this intermittent issue with the API calls. Initially, I thought it might be related to network latency, but after running diagnostics and checking the server logs, I pinpointed a problem with the request timeout settings. It turns out, we had set them too low for some of our users—leading to premature connection closures. Which of the following best describes
John's debugging narration, focusing on clarity for a code review?John's narration effectively follows a common debugging pattern: identifying an initial hypothesis, systematically eliminating it through investigation (diagnostics, log checks), and then presenting the definitive cause. This structure is crucial for code reviews because it demonstrates a logical thought process and provides concrete evidence supporting the resolution. The key here is that John clearly articulates *how* he ruled out his first suspicion, rather than simply stating what the problem was.9 / 26
PR Description:
"Fixed a bug where users were occasionally seeing incorrect order totals. Initially suspected an issue with the cart calculation logic, but after reviewing the code and adding more detailed logging around the decimal arithmetic, I discovered that rounding errors in the database were causing discrepancies. The fix involved applying a small tolerance value to the calculations."This response is correct because it clearly outlines the debugging process. The explanation details the problem, the investigative steps (reviewing code and adding logging), and the solution—all key components of effective debugging narration. Options A and C are incorrect as they focus on irrelevant aspects, while option D misinterprets what constitutes a good PR description.
10 / 26
Mark: 'Okay, so I've been looking at this intermittent error with the payment processing. My first thought was a problem with the API integration – specifically, maybe we weren't handling the response correctly. I checked the logs and added some extra debugging statements to the API call, but nothing showed up. Then I realized I hadn't considered potential issues within our own codebase, like a race condition during transaction updates.'This option best captures Mark's narrative as a structured debugging process. The key is that he first proposes a hypothesis (API issue), then demonstrates how he *tested* that hypothesis (checking logs and adding debug statements), and finally acknowledges the need to broaden his scope. Option A is too vague, B misrepresents his actions, C misses crucial elements of the progression, and D reflects a poor debugging strategy.
11 / 26
Alex: 'I've been wrestling with this deployment issue. I started by assuming it was a problem with the new version of the frontend, but after rolling back to the previous build and testing thoroughly, the error persisted. Then I checked the server logs, which didn't reveal anything obvious. Now I'm thinking it might be related to the database connection pool…'This scenario highlights a common debugging pattern: starting with an initial hypothesis and systematically testing it. Option 1 accurately describes Alex's narrative – he's outlining his investigation steps, acknowledging that his first assumption was incorrect, and still exploring potential causes. The other options misrepresent the process; 'correct' is too definitive, 'misleading' implies a wrong action, and 'incomplete' suggests missing information rather than a logical progression of thought during debugging.
12 / 26
Sarah: 'I spent the last two hours chasing this error. I initially suspected a race condition in the database writes, but after profiling and adding logging, I realized it was actually a misconfigured caching layer that was serving stale data. It's frustrating because I wasted so much time looking at the wrong thing!'
Which of the following best describes Sarah's debugging narration, focusing on clarity for a code review?Sarah's narration demonstrates a crucial element of debugging communication: clearly outlining the initial hypothesis, the subsequent investigation stages, and ultimately, the identified root cause. The mistake here is option D; while technical language can be appropriate in some contexts, it needs to be accessible to a broader audience during a code review. Option B is correct because it highlights the key elements of a good debugging narrative – progression, detail, and clarity about what was investigated.13 / 26
John: 'I've been digging into this intermittent issue with the API calls. Initially, I thought it might be related to network latency, but after running diagnostics and checking the server logs, I pinpointed a problem with the request timeout settings. It turns out, we had set them too low for some of our users—leading to premature connection closures. Which of the following best describes
John's debugging narration, focusing on clarity for a code review?John's narration effectively follows a common debugging pattern: identifying an initial hypothesis, systematically eliminating it through investigation (diagnostics, log checks), and then presenting the definitive cause. This structure is crucial for code reviews because it demonstrates a logical thought process and provides concrete evidence supporting the resolution. The key here is that John clearly articulates *how* he ruled out his first suspicion, rather than simply stating what the problem was.14 / 26
PR Description:
"Fixed a bug where users were occasionally seeing incorrect order totals. Initially suspected an issue with the cart calculation logic, but after reviewing the code and adding more detailed logging around the decimal arithmetic, I discovered that rounding errors in the database were causing discrepancies. The fix involved applying a small tolerance value to the calculations."This response is correct because it clearly outlines the debugging process. The explanation details the problem, the investigative steps (reviewing code and adding logging), and the solution—all key components of effective debugging narration. Options A and C are incorrect as they focus on irrelevant aspects, while option D misinterprets what constitutes a good PR description.
15 / 26
Mark: 'Okay, so I've been looking at this intermittent error with the payment processing. My first thought was a problem with the API integration – specifically, maybe we weren't handling the response correctly. I checked the logs and added some extra debugging statements to the API call, but nothing showed up. Then I realized I hadn't considered potential issues within our own codebase, like a race condition during transaction updates.'This option best captures Mark's narrative as a structured debugging process. The key is that he first proposes a hypothesis (API issue), then demonstrates how he *tested* that hypothesis (checking logs and adding debug statements), and finally acknowledges the need to broaden his scope. Option A is too vague, B misrepresents his actions, C misses crucial elements of the progression, and D reflects a poor debugging strategy.
16 / 26
Alex: 'I've been wrestling with this deployment issue. I started by assuming it was a problem with the new version of the frontend, but after rolling back to the previous build and testing thoroughly, the error persisted. Then I checked the server logs, which didn't reveal anything obvious. Now I'm thinking it might be related to the database connection pool…'This scenario highlights a common debugging pattern: starting with an initial hypothesis and systematically testing it. Option 1 accurately describes Alex's narrative – he's outlining his investigation steps, acknowledging that his first assumption was incorrect, and still exploring potential causes. The other options misrepresent the process; 'correct' is too definitive, 'misleading' implies a wrong action, and 'incomplete' suggests missing information rather than a logical progression of thought during debugging.
17 / 26
Sarah: 'I spent the last two hours chasing this error. I initially suspected a race condition in the database writes, but after profiling and adding logging, I realized it was actually a misconfigured caching layer that was serving stale data. It's frustrating because I wasted so much time looking at the wrong thing!'
Which of the following best describes Sarah's debugging narration, focusing on clarity for a code review?Sarah's narration demonstrates a crucial element of debugging communication: clearly outlining the initial hypothesis, the subsequent investigation stages, and ultimately, the identified root cause. The mistake here is option D; while technical language can be appropriate in some contexts, it needs to be accessible to a broader audience during a code review. Option B is correct because it highlights the key elements of a good debugging narrative – progression, detail, and clarity about what was investigated.18 / 26
John: 'I've been digging into this intermittent issue with the API calls. Initially, I thought it might be related to network latency, but after running diagnostics and checking the server logs, I pinpointed a problem with the request timeout settings. It turns out, we had set them too low for some of our users—leading to premature connection closures. Which of the following best describes
John's debugging narration, focusing on clarity for a code review?John's narration effectively follows a common debugging pattern: identifying an initial hypothesis, systematically eliminating it through investigation (diagnostics, log checks), and then presenting the definitive cause. This structure is crucial for code reviews because it demonstrates a logical thought process and provides concrete evidence supporting the resolution. The key here is that John clearly articulates *how* he ruled out his first suspicion, rather than simply stating what the problem was.19 / 26
PR Description:
"Fixed a bug where users were occasionally seeing incorrect order totals. Initially suspected an issue with the cart calculation logic, but after reviewing the code and adding more detailed logging around the decimal arithmetic, I discovered that rounding errors in the database were causing discrepancies. The fix involved applying a small tolerance value to the calculations."This response is correct because it clearly outlines the debugging process. The explanation details the problem, the investigative steps (reviewing code and adding logging), and the solution—all key components of effective debugging narration. Options A and C are incorrect as they focus on irrelevant aspects, while option D misinterprets what constitutes a good PR description.
20 / 26
Mark: 'Okay, so I've been looking at this intermittent error with the payment processing. My first thought was a problem with the API integration – specifically, maybe we weren't handling the response correctly. I checked the logs and added some extra debugging statements to the API call, but nothing showed up. Then I realized I hadn't considered potential issues within our own codebase, like a race condition during transaction updates.'This option best captures Mark's narrative as a structured debugging process. The key is that he first proposes a hypothesis (API issue), then demonstrates how he *tested* that hypothesis (checking logs and adding debug statements), and finally acknowledges the need to broaden his scope. Option A is too vague, B misrepresents his actions, C misses crucial elements of the progression, and D reflects a poor debugging strategy.
21 / 26
Alex: 'I've been wrestling with this deployment issue. I started by assuming it was a problem with the new version of the frontend, but after rolling back to the previous build and testing thoroughly, the error persisted. Then I checked the server logs, which didn't reveal anything obvious. Now I'm thinking it might be related to the database connection pool…'This scenario highlights a common debugging pattern: starting with an initial hypothesis and systematically testing it. Option 1 accurately describes Alex's narrative – he's outlining his investigation steps, acknowledging that his first assumption was incorrect, and still exploring potential causes. The other options misrepresent the process; 'correct' is too definitive, 'misleading' implies a wrong action, and 'incomplete' suggests missing information rather than a logical progression of thought during debugging.
22 / 26
Sarah: 'I spent the last two hours chasing this error. I initially suspected a race condition in the database writes, but after profiling and adding logging, I realized it was actually a misconfigured caching layer that was serving stale data. It's frustrating because I wasted so much time looking at the wrong thing!'
Which of the following best describes Sarah's debugging narration, focusing on clarity for a code review?Sarah's narration demonstrates a crucial element of debugging communication: clearly outlining the initial hypothesis, the subsequent investigation stages, and ultimately, the identified root cause. The mistake here is option D; while technical language can be appropriate in some contexts, it needs to be accessible to a broader audience during a code review. Option B is correct because it highlights the key elements of a good debugging narrative – progression, detail, and clarity about what was investigated.23 / 26
John: 'I've been digging into this intermittent issue with the API calls. Initially, I thought it might be related to network latency, but after running diagnostics and checking the server logs, I pinpointed a problem with the request timeout settings. It turns out, we had set them too low for some of our users—leading to premature connection closures. Which of the following best describes
John's debugging narration, focusing on clarity for a code review?John's narration effectively follows a common debugging pattern: identifying an initial hypothesis, systematically eliminating it through investigation (diagnostics, log checks), and then presenting the definitive cause. This structure is crucial for code reviews because it demonstrates a logical thought process and provides concrete evidence supporting the resolution. The key here is that John clearly articulates *how* he ruled out his first suspicion, rather than simply stating what the problem was.24 / 26
PR Description:
"Fixed a bug where users were occasionally seeing incorrect order totals. Initially suspected an issue with the cart calculation logic, but after reviewing the code and adding more detailed logging around the decimal arithmetic, I discovered that rounding errors in the database were causing discrepancies. The fix involved applying a small tolerance value to the calculations."This response is correct because it clearly outlines the debugging process. The explanation details the problem, the investigative steps (reviewing code and adding logging), and the solution—all key components of effective debugging narration. Options A and C are incorrect as they focus on irrelevant aspects, while option D misinterprets what constitutes a good PR description.
25 / 26
Mark: 'Okay, so I've been looking at this intermittent error with the payment processing. My first thought was a problem with the API integration – specifically, maybe we weren't handling the response correctly. I checked the logs and added some extra debugging statements to the API call, but nothing showed up. Then I realized I hadn't considered potential issues within our own codebase, like a race condition during transaction updates.'This option best captures Mark's narrative as a structured debugging process. The key is that he first proposes a hypothesis (API issue), then demonstrates how he *tested* that hypothesis (checking logs and adding debug statements), and finally acknowledges the need to broaden his scope. Option A is too vague, B misrepresents his actions, C misses crucial elements of the progression, and D reflects a poor debugging strategy.
26 / 26
Alex: 'I've been wrestling with this deployment issue. I started by assuming it was a problem with the new version of the frontend, but after rolling back to the previous build and testing thoroughly, the error persisted. Then I checked the server logs, which didn't reveal anything obvious. Now I'm thinking it might be related to the database connection pool…'This scenario highlights a common debugging pattern: starting with an initial hypothesis and systematically testing it. Option 1 accurately describes Alex's narrative – he's outlining his investigation steps, acknowledging that his first assumption was incorrect, and still exploring potential causes. The other options misrepresent the process; 'correct' is too definitive, 'misleading' implies a wrong action, and 'incomplete' suggests missing information rather than a logical progression of thought during debugging.
Frequently Asked Questions
What does the "Debugging Narration" exercise practise?
Narrate debugging investigations using noticed/suspected/tested/found/fixed structure. Practice past tense, ruling out hypotheses, and communicating findings. Intermediate exercises.
How many questions are in this exercise?
This exercise has 26 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Debugging Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Debugging Narration" part of a larger series?
Yes — it's one exercise in the Debugging Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Debugging Language category page for related exercises, or browse the main Exercises hub for other IT English topics.