TECH ENGLISH

Pull Request Feedback

Learn how to write clear, constructive PR comments in English and respond to feedback professionally — from nit-picks to blocking issues.

Practice Tech Discussions

Scenario Context

You're reviewing a large PR that refactors the authentication module. Some changes are great, but you've found a security concern in the token validation logic and several naming inconsistencies. You need to leave comments that are helpful without being overwhelming, and categorize them by severity.

Why This Matters for Engineers

Pull request feedback is the primary written communication channel between engineers on a team. Poorly worded comments can create conflict, slow down development, and damage team morale. Conversely, clear, constructive feedback accelerates delivery and builds trust. Non-native speakers often struggle with tone in written English — what feels direct in their native language may come across as harsh or dismissive in English. Learning the right conventions and phrases for PR feedback is essential for effective collaboration.

Essential Phrases

“Nit: Can we use camelCase here for consistency with the rest of the codebase?”

Minor style feedback

casual

“Blocking: This token validation doesn't check for expiry, which is a security concern.”

Critical issue

formal

“Suggestion: Consider using a guard clause here to reduce nesting.”

Code improvement

neutral

“Question: What's the reasoning behind using a string comparison here instead of a constant?”

Asking for context

neutral

“Nice refactor! This is much more readable than the previous version.”

Positive feedback

casual

“Optional: We could add a JSDoc comment here to explain the algorithm.”

Documentation suggestion

neutral

“I'd recommend adding error handling for the case where the token is malformed.”

Requesting error handling

formal

“This is great work overall — just a few comments inline.”

Overall feedback

casual

“Could you explain the motivation for this change? I want to make sure I'm reviewing with the right context.”

Requesting context

formal

“I tested this locally and it works as expected. LGTM!”

Approving after testing

casual

Technical Pronunciation

Word	❌ Common Error	✅ Correct	Tip
refactor	REE-factor	ree-FAK-tor	Stress on the second syllable: FAK.
linting	LINE-ting	LIN-ting	Short 'i' sound, like 'mint'.
regex	REG-ex	REJ-ex	The 'g' has a soft 'j' sound.
boolean	BOO-lee-an	BOO-lee-uhn	Three syllables. Named after George Boole.
concatenate	kon-KAT-en-ate	kon-KAT-uh-nayt	Four syllables, stress on KAT.

Written vs. Spoken English

Engineers often write one way on Slack or GitHub, but speak differently in meetings. Here's how to translate.

Blocking feedback

Written (Slack/PR)

Blocking: Missing token expiry validation. This presents a security vulnerability per RFC 7519 Section 4.1.4.

Spoken (Meeting)

“This is a blocking issue — we're not checking if the token is expired, which could let someone use an old token to log in.”

Minor feedback

Written (Slack/PR)

Nit: Rename `tmpArr` to `validatedTokens` for clarity.

Spoken (Meeting)

“Small thing — can we give this variable a more descriptive name? 'tmpArr' doesn't tell me much.”

Praise

Written (Slack/PR)

Clean separation of concerns in the session management refactor.

Spoken (Meeting)

“Love how you separated the session logic — it's way cleaner now.”

Example Dialogue

YouHey, I've gone through the PR. Really nice work on the refactor — the auth module is much cleaner now.

ColleagueThanks! I spent a lot of time simplifying the token flow. Were there any concerns?

YouOne important one — in the token validation function, I don't see a check for token expiry. If we skip that, an expired token could still be accepted.

ColleagueOh, you're right. I assumed the upstream middleware handles that, but we shouldn't rely on it.

YouExactly. I left it as a blocking comment. Once that's fixed, the rest is just nits — some naming inconsistencies and a suggestion to use guard clauses in a couple of places.

ColleagueGot it. I'll address the security fix first and push an update.

YouSounds good. I also left a few positive comments — the way you refactored the session manager is really elegant.

ColleagueAppreciate that! I'll ping you once the fix is up.

YouPerfect — I'll re-review and approve once the blocking issue is resolved.

Common Questions

What's the difference between 'nit', 'suggestion', and 'blocking' in PR reviews?

A 'nit' is a trivial issue (naming, formatting) that shouldn't block merging. A 'suggestion' is a recommended improvement that would make the code better. 'Blocking' means the PR cannot be merged until this is fixed — usually for bugs, security issues, or breaking changes.

How do I respond when someone leaves harsh PR feedback?

Stay professional. Assume positive intent and ask for clarification: 'Thanks for the feedback — could you elaborate on what you'd suggest instead?' If the tone is consistently harsh, address it privately: 'I appreciate thorough reviews, but the phrasing felt a bit blunt. Could we keep comments constructive?'

Should I leave comments on things I like in a PR?

Absolutely! Positive feedback is just as important as corrections. Comments like 'Nice pattern here!' or 'Love this approach — very readable' build team morale and encourage good practices.

Stop Stumbling on Tech Calls

Practice explaining code, architecture, and bugs with an AI coach that understands engineering context.

Start Practicing Now

No credit card required.

More Tech Scenarios

Code Review Discussions

Mentoring Junior Developers

Daily Standup Updates