How to Review Code Without Being a Jerk

I still remember my first Pull Request at my first "real" dev job.

I had spent three days wrestling with a complex API integration. I felt like a wizard. I pushed the code, opened the PR, and leaned back in my chair, waiting for the applause.

20 minutes later, the notification pinged. "Changes Requested."

I opened it up to find 42 comments. The very first one read:

"Why did you do it this way? This makes no sense."

My impostor syndrome kicked down the door and started setting fires in my brain. I didn't feel mentored; I felt attacked.

Now that I’m a Senior Developer, I realize that the reviewer probably wasn't trying to be mean. They were likely just busy, tired, or lacking soft skills. But the result was the same: my morale tanked, and I became terrified of submitting code.

Code reviews are the primary way we share knowledge, but they are also a minefield for miscommunication. Here is how to give high-quality feedback without becoming the villain of the story.

1. Critique the Code, Not the Coder

This is the Golden Rule. When you use the word "You," it feels personal. When you talk about the code, it’s objective.

The "Jerk" Way:

"You forgot to close the database connection here."

The Senior Way:

"It looks like the database connection might remain open here. We should probably close it to prevent leaks."

Why it works: It shifts the dynamic from Me vs. You to Us vs. The Bug. We are on the same team, trying to defeat the spaghetti code together.

2. Ask Questions, Don't Bark Commands

Commands shut down conversation. Questions open a dialogue. As a senior, your goal isn't just to fix the code; it's to teach the junior how to think.

The "Jerk" Way:

"Rename this variable to isUserActive."

The Senior Way:

"This variable name flag is a bit ambiguous. What do you think about naming it isUserActive to make it clearer for the next person reading this?"

Sometimes, the developer actually has a reason for doing it their way. By asking a question, you give them the chance to explain (and sometimes, they might actually be right!).

3. The Magical Power of "Nitpick"

Nothing destroys the soul quite like a reviewer holding a PR hostage because of indentation or a missing trailing comma.

If a comment is purely subjective (preference) or minor style, label it.

[Nitpick]

[Optional]

[Suggestion]

Example:

"[Nitpick] I usually prefer using a ternary operator here for brevity, but this if/else works too. Feel free to leave it."

This tells the developer: "Your logic is solid, you can merge this, but here is a tip for next time." It removes the anxiety of "I have to fix everything before I am worthy."

4. Don't Be a Ghost 👻

We’ve all seen the reviewer who leaves a comment like:

"This isn't efficient."

...and then disappears into the void.

If you are going to call something out, explain why. Provide a link to documentation, a StackOverflow thread, or a quick snippet of how it could be better.

The Senior Way:

"Using .map inside a .filter here creates a O(n^2) complexity. Since this dataset can get huge, this might slow down the UI. Check out [this article on Big O notation]—we might want to use a Set here instead."

5. Praise is Mandatory (Seriously) 🏆

This is the secret weapon of great Tech Leads.

If you are pointing out 10 mistakes, find at least one thing they did well. Did they write a clean test? Did they handle a weird edge case gracefully? Tell them!

"Nice catch on that null check! I would have totally missed that."

Positive reinforcement makes people want to write better code. Constant criticism makes people want to write safe code (which is often boring and stagnant).

6. The "Step Away From The Keyboard" Rule

If you find yourself typing a comment that is longer than a paragraph, or if you and the author are going back and forth on a comment thread more than three times...

Stop.

Pick up the phone. Hop on a Slack Huddle. Walk over to their desk.

Text lacks tone. What you think is a "direct explanation" might read as "passive-aggressive shouting." A 3-minute voice conversation can resolve what 3 hours of comment-warfare cannot.

Summary: Be the Senior You Needed
Code review isn't about proving you are the smartest person in the room. It's about ensuring the team ships value safely.

Be kind.

Be specific.

Be a mentor.

Your teammates will learn more from a helpful guide than a gatekeeper.

Happy coding!

If you found this helpful, drop a ❤️ and let me know in the comments: What's the worst (or best) code review comment you've ever received?