5 exercises — Professional email communication around code reviews: responding to feedback, requesting re-reviews, writing approvals, and following up on stalled PRs.
0 / 5 completed
1 / 5
You submitted a PR and a reviewer left this comment: "This approach seems inefficient." You disagree and have profiling data to prove your point. How do you respond by email?
Effective pushback on code review feedback: acknowledge the concern, lead with data, offer collaboration.
Structure of a professional technical disagreement by email:
1. Acknowledge: "I see your concern about…" — shows you read and understood
2. Evidence: specific numbers from profiling (12ms vs 18ms)
3. Collaborative offer: "Happy to walk through… if that would help" — keeps the tone collegial
What to avoid:
• "You're wrong" — confrontational, damages the relationship
• Just capitulating — silent acceptance of incorrect feedback erodes code quality
• "I don't think" — too weak; data is more persuasive than opinion
Key vocabulary:
• benchmark — a test that measures performance under defined conditions
• profiler output — data from a profiling tool showing where time is spent
• "walk through" — to explain something step by step
• collegial — friendly and cooperative among colleagues
2 / 5
A reviewer left 12 comments on your PR, including 3 blocking ones. You've addressed all of them. Which email to the reviewer is most professional?
A re-review request should make the reviewer's job easy: tell them what changed, where, and why.
The ideal re-review request includes:
• Scope summary: "addressed all 12 comments"
• Blocking issues resolved: named with commit references
• Non-blocking items: acknowledged (shows you read them, even if not acted on)
• Polite ask: "when you have a moment" — respects their time
Why linking to commits is important:
• Reviewers can jump directly to the relevant diff
• Shows traceability — each change is documented
• Prevents "where did you change X?" back-and-forth
Key vocabulary:
• blocking issue — a comment that must be resolved before the PR can be merged
• non-blocking — a suggestion the author can accept or decline at their discretion
• acknowledged inline — replied to within the PR thread (even if not acted on)
• commit reference / SHA — the unique identifier for a specific git commit
3 / 5
You are the reviewer and want to send a summary email after approving a large architectural PR. Which message is most useful?
A meaningful approval does more than unblock the PR — it teaches, reinforces good patterns, and opens dialogue.
What a great approval message includes:
• Explicit decision: "Approved" — unambiguous
• Specific praise: "solid implementation of the event sourcing pattern" — names what was done well
• Forward-looking guidance: "worth considering before the next event-driven feature" — helps the author improve
• Reference to specific comments: #4 and #7 — reviewable
• Offer to discuss: "happy to discuss offline" — collegial
Why "LGTM 👍" is insufficient for large architectural PRs:
• No learning opportunity for the author
• No documentation of what was reviewed
• No guidance for future similar work
Key vocabulary:
• LGTM — "Looks Good To Me" — approval abbreviation, fine for small PRs
• architectural PR — a pull request making significant structural changes to the codebase
• aggregate naming convention — naming rules for domain objects in event-driven or DDD architecture
• "offline" — in a separate meeting or direct conversation, outside the PR thread
4 / 5
A PR has been stuck in review for 5 days with no response. You need to send a follow-up. Which message is most effective?
A professional follow-up on a stalled PR: state the facts, explain the business impact, offer a solution, and make it easy for the reviewer to respond.
Elements of an effective follow-up:
• Specific reference: "PR #432" — no ambiguity about which PR
• Timeline: "since Monday" — factual, not accusatory
• Business impact: "blocking the Q3 onboarding feature" — gives urgency a reason
• Request with alternative: "or suggest another reviewer if you're overloaded" — gives them an out
• Offer to help: "happy to walk through the changes" — reduces the reviewer's activation energy
What to avoid:
• Accusatory tone: "Why haven't you…" makes people defensive
• "ASAP" and "urgent" without context — overused and lose meaning
• Merging without review — skips the safety net
Key vocabulary:
• stalled PR — a pull request that hasn't been reviewed or progressed
• blocking — preventing another piece of work from being completed
• "overloaded" — too busy to take on additional work
• "activation energy" — the effort required to start a task
5 / 5
After a difficult code review where several heated comments were exchanged, you want to send a follow-up to the reviewer to reset the relationship. Which message is best?
A relationship-repair message after a difficult review: acknowledge the difficulty, find the genuine positive, be specific about what you learned.
Why Option C works:
• Acknowledges the tension: "I know some of the back-and-forth was tense" — validates both experiences
• Finds genuine appreciation: "I appreciate that you care about the architecture" — attributes positive intent
• Specific learning: "your comments on the event boundary design" — shows you actually read and valued the feedback
• Forward-looking: "will apply that thinking in future PRs" — closes the loop professionally
Why the others fall short:
• Option A reopens the conflict ("unfair")
• Option B is dismissive — "no hard feelings" doesn't acknowledge or repair
• Option D is too vague — "more collaboratively" doesn't name what you appreciated
Key vocabulary:
• "back-and-forth" — an exchange of responses, especially a tense or lengthy one
• "attribute positive intent" — assume the other person meant well, even if the delivery was rough
• "close the loop" — complete a conversation or task so all parties feel it's resolved
• "event boundary design" — in domain-driven design, how events are scoped between bounded contexts