The Review Etiquette: Reviewing Code Without Being a Jerk

Something I saw on my LinkedIn feed this week: "I instantly lose all respect for juniors who can't explain every line of (AI-generated) code." Strong opinions are fine, but the way this was framed felt more hostile than helpful. Of course we should expect developers to understand their code. But if we want strong, reliable teams, we need more than just high standards, we need psychological safety too. If you dismiss someone’s potential this quickly it doesn’t help them grow. It creates fear and silence. For example, when I reviewed pull requests I was mainly thinking: ✅ Does it work? ✅ Is the syntax correct? ✅ No commented-out code? Cool. Ready to merge. Right? Well, not entirely. What I kept missing was the bigger picture: Does this code fit the overall architecture? Are we duplicating logic that already exists elsewhere? Can this function be reused in the future? I didn’t even know I should be asking those questions. But over time, and with the help of patient senior devs, I learned. And I learned something even more important: how you review matters just as much as what you say. Bad vs. Good Feedback ❌ “This is wrong.”, "This will not work." ✅ “This could break when X happens, maybe extract it into a reusable function? Let me know your thoughts.” That one simple shift, from judgment to curiosity, turns a code review into a conversation. Good code reviews aren’t monologues. They’re dialogues. Ask questions. Invite people in. Help them think, don’t just tell them they’re wrong. Feedback Sometimes Hurts (And That’s Okay) I’ve had feedback that stung. One senior told me I was relying too much on existing code and not thinking through my own solutions. Ouch. But also: true. And it helped me grow. Key mindset? Feedback is data, not a personal attack. It’s not about your worth. It’s about your work. 3 Review Rules I Try to Follow ✅ Explain why, not just what ✅ Suggest improvements, not just point out flaws ✅ Mind your tone: kind ≠ unclear Bonus: Always thank someone for reviewing your code. They took time out of their day to help you grow. Final thoughts If you're trying to grow toward a senior or lead role, your review style will make or break your influence. Start practicing the kind of feedback culture you want to be part of. And remember: you’re not just reviewing code. You’re reviewing someone’s effort.

Apr 21, 2025 - 18:05

The Review Etiquette: Reviewing Code Without Being a Jerk

Something I saw on my LinkedIn feed this week: "I instantly lose all respect for juniors who can't explain every line of (AI-generated) code."

Strong opinions are fine, but the way this was framed felt more hostile than helpful.

Of course we should expect developers to understand their code. But if we want strong, reliable teams, we need more than just high standards, we need psychological safety too. If you dismiss someone’s potential this quickly it doesn’t help them grow. It creates fear and silence.

For example, when I reviewed pull requests I was mainly thinking:

✅ Does it work?
✅ Is the syntax correct?
✅ No commented-out code?

Cool. Ready to merge. Right?

Well, not entirely. What I kept missing was the bigger picture:

Does this code fit the overall architecture?
Are we duplicating logic that already exists elsewhere?
Can this function be reused in the future?

I didn’t even know I should be asking those questions. But over time, and with the help of patient senior devs, I learned.

And I learned something even more important: how you review matters just as much as what you say.

Bad vs. Good Feedback

❌ “This is wrong.”, "This will not work."
✅ “This could break when X happens, maybe extract it into a reusable function? Let me know your thoughts.”

That one simple shift, from judgment to curiosity, turns a code review into a conversation. Good code reviews aren’t monologues. They’re dialogues. Ask questions. Invite people in. Help them think, don’t just tell them they’re wrong.

Feedback Sometimes Hurts (And That’s Okay)

I’ve had feedback that stung. One senior told me I was relying too much on existing code and not thinking through my own solutions.

Ouch. But also: true. And it helped me grow.

Key mindset?

Feedback is data, not a personal attack.

It’s not about your worth. It’s about your work.

3 Review Rules I Try to Follow

✅ Explain why, not just what
✅ Suggest improvements, not just point out flaws
✅ Mind your tone: kind ≠ unclear

Bonus: Always thank someone for reviewing your code. They took time out of their day to help you grow.

Final thoughts

If you're trying to grow toward a senior or lead role, your review style will make or break your influence. Start practicing the kind of feedback culture you want to be part of.

And remember: you’re not just reviewing code. You’re reviewing someone’s effort.