How I Stopped Writing 'Please Kindly Review' in Every Pull Request

For the first year at my remote job, every pull request I opened started the same way: "Dear reviewers, please kindly review this PR at your earliest convenience. Thank you in advance for your time and feedback."

I thought I was being professional. My colleagues in Portland probably thought I was writing a letter to the queen.

Nobody said anything directly. The code got reviewed, comments got resolved, PRs got merged. But I noticed something: my teammates' PR descriptions looked completely different from mine. They wrote things like "Adds retry logic to the payment webhook handler. Fixes #342." No "dear." No "kindly." No "at your earliest convenience."

It took me a while to understand that in developer communication, being direct isn't rude — it's actually the norm.

Where the habit came from

In Chinese business culture, politeness markers are important. When I write an email in Chinese to a colleague, I use formal greetings and softening phrases. The equivalent of "please kindly" (请您) is standard, expected, even required in some contexts. Omitting it can come across as blunt or disrespectful.

When I started working in English, I translated these patterns directly. Every message began with a polite opener. Every request included "would you be so kind as to" or "I would be grateful if you could." I was applying Chinese email etiquette to GitHub pull requests — two contexts with very different norms.

The phrase "please kindly" is a particular trap. In Chinese, stacking politeness modifiers makes you sound more respectful. In English, "please kindly" is redundant — "please" and "kindly" mean essentially the same thing. Using both together signals that the writer isn't a native speaker. It's not wrong, exactly, but it stands out.

The PR description that changed things

One day, my tech lead opened a PR with this description:

Refactors the auth middleware to support multiple token types. This is prep work for the OAuth integration next sprint.

Changes:
- Extracts token validation into a strategy pattern
- Adds JWT and API key validators
- Updates existing tests, adds tests for API key flow

Note: the OAuth handler itself isn't included here — keeping this PR focused on the refactor.

No greeting. No "please review." Just clear, structured information about what changed and why. The description respected the reviewer's time by being scannable and informative.

I realized my PR descriptions weren't just overly formal — they were also lacking useful content. I spent words on politeness that could have been spent on context. A reviewer opening my PR had to read past the pleasantries to find out what the PR actually did.

Learning the register of code review

Code review has its own register — a specific level of formality and set of conventions that differ from email, Slack, and documentation. I started paying attention to how experienced developers wrote in this context:

• PR titles are short and descriptive: "Fix race condition in queue consumer" not "Fixed an issue with the queue"
• PR descriptions explain what and why, not how (the diff shows how)
• Review comments are direct: "This could be a map instead of a for loop" not "Would it be possible to perhaps consider using a map here?"
• Nits are explicitly labeled: "nit: spacing" tells the author it's minor and non-blocking
• "LGTM" means approval. No need for "This looks great, I thoroughly reviewed every line and I'm happy to approve this excellent work."

The key insight: in code review, clarity is politeness. A reviewer who writes "This will break if the input is null" is being respectful of the author's time — they've identified a bug concisely. Wrapping it in three sentences of softening language actually makes it harder to parse.

The templates I started using

I didn't go from formal to casual overnight. I created mental templates that felt comfortable while matching the team's register:

For PR descriptions: start with one sentence summarizing the change. Then a short list of what's included. Then any context the reviewer needs (related issues, deployment notes, things to watch out for).

For review comments: state the observation or suggestion directly. Add a brief reason if it's not obvious. If it's minor, prefix with "nit:". If it's blocking, say so clearly.

For responding to feedback: "Good catch, fixed" or "Makes sense, updated" instead of "Thank you so much for pointing this out, I have made the correction as suggested."

The hardest part wasn't the words

The hardest part was the feeling that I was being rude. Every time I wrote a direct comment without softening language, a small voice in my head said "that sounds aggressive." It took months to internalize that directness in code review is not the same as directness in personal conversation.

What helped was DevGlish's context awareness. When I looked up phrases I wasn't sure about, it would tell me whether something was appropriate for code review, Slack, or email. Knowing that "Can you take another look?" is perfectly polite for a code review context — even though it might seem too casual for a Chinese business email — gave me permission to write naturally.

I also started reading more open-source PR threads. Projects like React, Kubernetes, and VS Code have thousands of public code reviews. Reading how contributors from all over the world communicate helped me calibrate my own style.

Where I am now

My PR descriptions are shorter, clearer, and more useful. My review comments are direct but not harsh. I still occasionally catch myself typing "please kindly" out of muscle memory, but I delete it before submitting.

The funny thing is, once I relaxed my writing style, I actually felt closer to my teammates. The formal language had been creating an invisible barrier — a sense that I was performing professionalism rather than just communicating. Dropping it made my interactions feel more genuine.

If you recognize yourself in this story, here's my advice: go read the last 20 PR descriptions from senior engineers on your team. Notice the patterns. Notice what they don't include. Then try matching that register in your next PR. It might feel uncomfortable at first, but your reviewers will appreciate it — and you'll save a lot of keystrokes.