Code Review: How to Do It Well and Receive It Better

👉 Motivated beginners, career changers, and tech enthusiasts who want to improve quickly without burning themselves out.

👉 People who want to learn independently while still growing with others.

👉 You, if you want to become a developer and master real professional practices, not just syntax.

- You are now in reviewer mode. You open a PR. Before clicking “Comment”, take a second.

Pause. Put yourself in the shoes of the person who wrote the code.

1.1. Start by Understanding the “Why”

“I don’t understand what they were trying to do…”

→ Maybe you have not read enough context yet.

- Before reading a single line of code, read the PR description.

What is the goal?
Which ticket is associated with it?
What tests have been performed?

- Be a facilitator:

“Hi! Could you add a short paragraph explaining the goal of this change? It would help me understand the context better. Thanks!”

- A standardized PR template on GitHub or GitLab can make a huge difference. Useful sections include:

• 🎯 Goal
• 🔧 Key changes
• ✅ Tests performed
• ⚠️ Points to watch

Fewer back-and-forth discussions, more clarity.

1.2. Read the Code… as If You Had to Maintain It Tomorrow

Imagine you have to work on this code again in six months, with nobody around to explain it.

Ask yourself these simple questions:

Is it readable?
Does it follow the team’s conventions?
Are there hidden bugs or performance issues?
Is it really necessary? Is it tested?

Concrete example:

You see a nested for loop running over a list of 10,000 elements.

→ Complexity: O(n²).

→ In production, that could become a serious performance issue.

Instead of saying: “This is slow.”

Suggest:

“Could we use a Set here? That could reduce the complexity to O(n) and help avoid a slowdown in production.”

→ You are helping, not humiliating.

1.3. Give Feedback That Builds, Not Feedback That Breaks

Tone matters.

Compare these two messages:

“This is badly named. Redo it.”

✅ “The variable tmp is a little vague. What if we called it userSessionId? That way, everyone immediately knows what it contains.”

The difference? → Constructiveness.

- Here are three useful approaches:

1. The gentle suggestion: “Could we extract this logic into a function? That would let us reuse it elsewhere.”
2. The open question: “Why did you choose this approach? Was there a specific constraint?”
3. The clear distinction:“This point is blocking because of security, but the variable name is only a suggestion.”

- Use labels:

• 🔴 Blocking: security issue, critical bug
• 💡 Suggestion: possible improvement
• ✨ Nitpick: small style detail such as indentation or naming

And when you reference a standard or practice, add a link when useful.

→ It turns feedback into learning.

1.4. Turn the Review into a Conversation, Not a Monologue

Code review is a discussion, not a verdict.

If a change is complex, suggest a pair-programming session.

Or a quick Slack/Teams call.

“I’m not 100% sure I understand your approach. Want to do a quick 10-minute call?”

→ It shows that you want to understand, not impose.

And sometimes… you are the one who learns something new.

You have just pushed your PR. You are proud of it.

And then… 3 comments. One of them is red: “Blocking”.

“But… I tested everything!”

Take a moment.

Again: this is not about you personally.

2.1. Separate Yourself from the Code: It Is Not a Personal Attack

Your code is not you.

You are not a bad developer because someone suggests an improvement.

You are learning.

“My PR was rejected.” → No.

“My PR was improved.” → Yes.

🧠 Simple metaphor:

A football player does not take it personally when the coach says: “That was a good dribble, but try crossing the ball earlier.”

That is coaching, not rejection.

2.2. Be Open, Responsive… and Appreciative

Read every comment carefully.

If you do not understand something, ask:

“Could you explain why this approach would be better?”

If you disagree, explain calmly:

“I chose this solution because of X, but I’m open to other ideas.”

And most importantly: respond in a reasonable timeframe.

→ It shows professionalism and respect for the team.

💡 Useful responses:

• “Thanks for the suggestion. I’ll implement it.”
• “Good point. I hadn’t considered that edge case.”
• “Interesting! I’ll test that alternative.”

2.3. Learn, Evolve, and Improve

After each review, take five minutes and ask:

“What did I learn today?”

Did you forget a test?

→ Add an item to your personal checklist: “Check edge cases.”

Did you choose a poor variable name?

→ Add a reminder: “Use clear names, always.”

👉 That is how you improve: not by being perfect, but by staying curious.

You are not alone. Automation can help.

Automation: Your Silent Ally

• GitHub Actions or Jenkins: run tests automatically.
• Linters such as ESLint and Prettier: handle many style issues automatically.
• SonarQube: detects bugs, technical debt, and security vulnerabilities.

👉 The result? Reviewers can focus on the important parts instead of indentation.

Team Checklist — Ready to Copy

Share it in a Notion document or README:

• ✅ Is the code readable? Are variable names clear?
• ✅ Is there unnecessary duplication?
• ✅ Does it follow team conventions?
• ✅ Are edge cases handled?
• ✅ Are unit and integration tests included?
• ✅ Security: injection risks or data leaks?
• ✅ Performance: expensive loops or repeated calls?
• ✅ Is the PR reasonably small and focused?

Review SLA: Avoid Bottlenecks

• Agree on a reasonable response time
• Keep reviews focused enough to complete efficiently
• Break very large PRs into smaller ones

→ This prevents queues and respects everyone’s time.

Pitfalls to Avoid — Even Experienced Developers Fall Into Them

❌ Too many nitpicks:

“The indentation is 3 spaces instead of 4.”

→ Fine to mention, but it should not overshadow more important issues.

Focus first on correctness, design, security, and maintainability.

❌ Monster PRs:

1,000 lines to review?

→ Nobody wants that.

Divide and conquer.

❌ Too harsh or too soft:

“This is terrible.” → No.

“Looks fine.” → Not enough either.

→ Be fair and useful.

❌ Ignoring automated reviews:

A tool reports a security issue?

→ Investigate it instead of ignoring it.