Thuan: QC just filed a bug: “Search feature doesn’t work.” That’s the entire description.
Alex: How does that make you feel?
Thuan: Angry? Defensive? I tested it myself — it works on my machine. And “doesn’t work” tells me nothing. But I can’t type that in a comment without sounding hostile.
Alex: This is the most emotionally charged communication in software teams. Bugs feel personal — QC says “this is broken” and the developer hears “you made a mistake.” Let’s build a communication toolkit that separates the code from the ego.
Responding to Bug Reports
When the Bug Report Is Clear
A good bug report has: steps to reproduce, expected behavior, actual behavior, environment. When you get one:
| Situation | Phrase |
|---|---|
| Confirmed bug | ”Confirmed. I can reproduce it. I’ll fix this — ETA: [time].” |
| Simple fix | ”Good catch — this was a missing null check. I’ll push a fix today.” |
| Complex bug | ”I can reproduce it. The root cause is in [area]. I’ll need [time] to investigate.” |
When the Bug Report Is Vague
| Bug Report Says | Your Response |
|---|---|
| ”Doesn’t work" | "Could you share the steps to reproduce? I tested with [X] and it works on my end." |
| "It’s broken" | "Which part specifically? Could you share a screenshot or error message?" |
| "I think there’s a bug" | "Could you describe the expected behavior vs. what you’re seeing?" |
| "Same bug as before" | "Could you link the original bug? I want to make sure it’s the same root cause.” |
Template for requesting more info:
“I’d like to look into this. To help me investigate, could you share:
- Steps to reproduce
- What you expected to see
- What actually happened
- Browser/device/environment”
Thuan: That’s polite but firm. I’m not saying “your bug report is bad” — I’m saying “help me help you.”
Alex: Exactly. And most QCs appreciate it. They want bugs fixed — giving them a template actually helps them.
Defending Your Code (Professionally)
Thuan: What about when QC reports something that’s not a bug? Like “the button should be blue” when the design says grey?
Alex: Two categories: “not a bug” and “works as designed."
"Not a Bug” — Polite Responses
| Situation | Phrase |
|---|---|
| Works as designed | ”This is actually the intended behavior per the requirements. The AC says [X]. Should we check with the BA?” |
| Environment issue | ”I think this might be an environment issue. Could you try clearing your cache or testing on staging?” |
| Test data issue | ”This looks like a test data issue — the account in your test doesn’t have the right permissions.” |
| Edge case not in scope | ”Good observation. This edge case isn’t covered in the current story. Should we create a new ticket for it?” |
The “Works on My Machine” Conversation
QC: “The login page returns a 500 error.”
Thuan: “I just tested it on staging and it’s working. Could you share your exact steps? Also, are you testing on the latest deployment? The latest build was pushed 30 minutes ago.”
QC: “Oh, I was on the old environment.”
Thuan: “No problem. Could you try again on staging and let me know?”
Alex: Notice: no sarcasm, no “I told you so.” Just helpful questions that guide them to the answer.
Accepting Valid Bugs (Without Dying Inside)
Thuan: Okay, but what about when it IS my bug? My ego doesn’t handle that well.
Alex: Here’s the professional response pattern:
Accepting a Bug Gracefully
| Situation | Phrase |
|---|---|
| Simple mistake | ”Good catch. I missed that case. Fixing now.” |
| Regression | ”You’re right — this is a regression from the refactoring. I’ll fix it and add a test to prevent it happening again.” |
| Serious bug | ”Thanks for catching this pre-production. This would have been a problem for users. I’m on it.” |
| Edge case | ”You’re right, I didn’t consider that scenario. I’ll add handling for it.” |
The Golden Rule: “Good catch” + action plan. That’s it. No lengthy explanations. No excuses.
Thuan: “Good catch” — it feels weird to thank someone for finding my mistake.
Alex: In English business culture, “good catch” is the highest-status response. It shows:
- You’re not defensive
- You prioritize product quality over ego
- You’re a professional who fixes things, not a person who makes excuses
Discussing Severity and Priority
Thuan: QC marks everything as “Critical.” How do I push back on severity?
Alex: Define the terms, then discuss:
| Severity | Meaning | Example |
|---|---|---|
| Critical | System is down, data loss, security breach | ”Users can’t log in” |
| High | Major feature broken, workaround exists | ”Search returns wrong results” |
| Medium | Minor feature broken, doesn’t block users | ”Sorting doesn’t work on mobile” |
| Low | Cosmetic issue, minor inconvenience | ”Date format inconsistent” |
Negotiating Severity
QC: “I marked this as critical — the date format is wrong.”
You: “I agree the date format needs fixing. However, ‘critical’ is usually for system-down scenarios. Would you be okay with ‘medium’? Users can still complete their tasks — it’s a display issue.”
QC: “Okay, medium makes sense.”
Phrase: “I agree this needs fixing. Could we adjust the severity to [X]? The impact is [Y], which aligns more with [severity level].”
The Bug Lifecycle Conversation
Alex: Here’s how a healthy bug lifecycle conversation looks:
Bug Reported
QC: “Bug: Checkout fails when cart has more than 50 items. Steps: add 51 items, click checkout, see 500 error.”
Thuan: “Reproducing now… confirmed. The query doesn’t handle pagination for large carts. Good catch — this would have hit power users.”
Bug Fixed
Thuan: “Fixed in PR #234. The issue was an unbounded query. I added pagination and a test for carts with 100+ items. Ready for re-test.”
QC: “Testing now… confirmed fixed. Closing the ticket.”
Bug Reopened
QC: “Reopening — the fix works for 50+ items, but now checkout fails for exactly 50 items.”
Thuan: “Ah, off-by-one error. Classic. Fixing now — will have a patch in an hour.”
Thuan: “Off-by-one error. Classic.” — I love the self-awareness.
Alex: Humor disarms tension. When you can laugh at your own mistake, nobody else needs to point it out.
Building a Good QC Relationship
Alex: Long-term, the best thing for your English (and your code) is a strong relationship with your QC:
| Practice | Phrase |
|---|---|
| Regular sync | ”Want to do a 15-minute sync before testing starts? I can walk you through what changed.” |
| Sharing context | ”Heads up — the checkout flow changed in this sprint. Here’s what to focus on.” |
| Thanking good reports | ”This bug report is really detailed. Makes my life much easier.” |
| Asking for input | ”Before I build this, any thoughts on what edge cases we should test?” |
| Cross-training | ”Want to pair for 30 minutes? I’ll show you the code and you show me your test scenarios.” |
10-Minute Self-Practice
The Bug Response Practice (5 min)
- Open a recent bug ticket from your project
- Write 3 different responses:
- If you agree it’s a bug
- If it’s “works as designed”
- If you need more information
- Say each response aloud
The Ego Check (5 min)
- Think of the last bug you were defensive about
- Rewrite your response using “Good catch” + action plan
- Practice saying it naturally: “Good catch — I’ll fix that today.”
- Notice how much easier it is to say once you’ve practiced it
Thuan: Practicing defenselessness. That’s a weird concept.
Alex: Athletes practice losing gracefully. Devs should practice accepting bugs gracefully. It’s the same muscle.
What’s Next
Bugs are no longer scary. Next post: Dev vs PM — Deadlines and Trade-offs — where you learn to say “no” to a project manager without losing your job.
This is Part 8 of the English Upgrade series. Pairs with English Upgrade #10: Code Review Communication — async communication about code quality.
Related: Tech Coffee Break #9: Security — because some bugs are security vulnerabilities, and those conversations have even higher stakes.