Principles of Code Review Feedback

In the last 11 years of my career, I’ve participated in code reviews almost daily. I’ve sat through 100s of review sessions with seniors and colleagues. Here’s how to make your code reviews smoother, faster and easier: 1. Start with Small, Clear Commits    - Break your changes into logical, manageable chunks. This makes it easier for reviewers to focus and catch errors quickly. 2. Write Detailed PR Descriptions    - Always explain the “why” behind the changes. This provides context and helps reviewers understand your thought process. 3. Self-Review Before Submitting    - Take the time to review your own code before submitting. You'll catch a lot of your own mistakes and improve your review quality. 4. Ask for Specific Feedback    - Don’t just ask for a “review”—be specific. Ask for feedback on logic, structure, or potential edge cases. 5. Don’t Take Feedback Personally    - Code reviews are about improving the code, not critiquing the coder. Be open to constructive criticism and use it to grow. 6. Prioritize Readability Over Cleverness    - Write code that’s easy to understand, even if it’s less “fancy.” Simple, clear code is easier to maintain and review. 7. Focus on the Big Picture    - While reviewing, look at how changes fit into the overall system, not just the lines of code. Think about long-term maintainability. 8. Encourage Dialogue    - Reviews shouldn’t be a one-way street. Engage in discussions and collaborate with reviewers to find the best solution. 9. Be Explicit About Non-Blocking Comments    - Mark minor suggestions as “nitpicks” to avoid confusion. This ensures critical issues get addressed first. 10. Balance Praise and Criticism    - Acknowledge well-written code while offering suggestions for improvement. Positive feedback encourages better work. 11. Always Follow Up    - If you request changes or leave feedback, follow up to make sure the feedback is understood and implemented properly. It shows you’re invested in the process. -- P.S: What would you add from your experience?

Code reviews aren’t about catching mistakes.   They’re about making better engineers.  Too many developers treat code reviews like a game of “gotcha.”   Pointing out tiny errors. Flexing knowledge. Nitpicking style over substance.  But here’s the truth:   No one gets better by being embarrassed.   They grow when they feel safe enough to ask, fail, and learn. Here’s what code reviews should not be:   ✘ A place to prove you're smarter   ✘ A way to score points or find faults   ✘ A ritual that leaves someone demotivated  And here’s what they should be:   ✔ A chance to teach, not preach   ✔ A way to share better practices   ✔ An opportunity to mentor, not monitor  Your job in a review isn’t just to approve or reject.   It’s to communicate.   To help the next dev avoid the same bug.   To explain the why, not just the what.   To help juniors feel confident, not scared. Be kind to the person. Be critical of the code.  That balance is where real growth happens. The best teams?   They treat reviews as a collaborative learning tool.   Not a quality gate. Not a judgement zone.  Because strong code comes from strong feedback.   But only when it comes from the right place.  Code is temporary.   How you made someone feel during the review? That sticks.  Don’t just review code.   Build trust. Share knowledge. Uplift people.  That’s how good engineers become great ones.

𝗧𝘄𝗼 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗿𝗲𝘃𝗶𝗲𝘄𝗲𝗱 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗰𝗼𝗱𝗲: One got fired One got promoted The difference? How they gave feedback 👇 "This is a security risk. Do you want us to get hacked?" ❌ "Let's sanitize inputs here to prevent potential vulnerabilities" ✅ "Why are you reinventing the wheel?" ❌ "Is there an existing library we could use here?" ✅ "Stop hardcoding values" ❌ "Ideally, let's move these constants to the config file" ✅ "You are swallowing the exception" ❌ "We should log the error details here for better debugging" ✅ "This query will kill the database" ❌ "Batching these requests might improve performance" ✅ "YAGNI. Delete this over-engineering" ❌ "Do we need this flexibility now, or can we simplify?" ✅ "Rewrite this file while you're at it" ❌ "Let's keep the scope tight. Can we refactor that in a separate ticket?" ✅ "I found 5 typos. Fix them" ❌ "I left some minor style nits, feel free to address them later" ✅ "Copy-pasting is for juniors" ❌ "This logic looks similar to X, can we abstract it?" ✅ "I have no idea what this code does" ❌ "Could you walk me through the logic? I am having trouble following" ✅ "This variable name is useless" ❌ "A more descriptive name for 'x' would help readability" ✅ "Why is this code even here?" ❌ "Is this block still reachable, or can we remove it safely?" ✅ "This isn't thread-safe" ❌ "Let's review the concurrency model here to avoid race conditions" ✅ "Read my previous comment!" ❌ "I think this point might have been missed from the last review" ✅ "This looks different from the rest of the app" ❌ "Let's match the existing pattern in the payment module for consistency" ✅ "I don't know how to test this" ❌ "Could you add reproduction steps to the PR description?" ✅ "You broke the build again" ❌ "Let's check the CI logs to see what caused the failure" ✅ "This solution is lazy" ❌ "I think we can find a more robust solution for the long term" ✅ "Don't merge until you fix everything" ❌ "The logic looks solid, just a few blockers to address before merge" ✅ (Silence when the code is good) ❌ "This is a really elegant solution, nice work!" ✅ Your code review checklist: ✅ Focus on the code, not the person ✅ Ask questions, don't make demands ✅ Use "We" instead of "You" ✅ Distinguish between "must-fix" and "nitpick" ✅ Praise good code publicly Which toxic review comment have you received? Share below 👇 — ♻️ Repost to help others create a better code review culture ➕ Follow me ( Anton Martyniuk ) to improve your .NET and Architecture Skills

I am a software engineer at Google who's worked in the UK, USA, and India offices, all because of the opportunities I've had here. During my first 3 months at Google, I went through the official Google guide on "How to handle reviewer comments" on a CL (which is like a pull request)...If you're a junior engineer reading this, always remember this:  1 // Don’t take it personally. When someone reviews your code, it’s not about you. It’s about the codebase. It’s about the company. And it’s about long-term quality. Think of it like this: If someone says, “This logic is unclear,” they’re not saying you’re unclear. They’re saying, “This piece of code won’t make sense to the next engineer who reads it 6 months from now.” It’s a conversation, do not get offended, but seek clarity…  2 // Clarify the code, not the comment box. One mistake I used to make early on: When someone didn’t understand my code, I’d explain it in the review thread. But the real fix is this: make the code speak for itself. If your reviewer doesn’t get it, a future dev won’t either. Rewrite. Refactor. Add a comment if needed. The review thread is temporary. The code is forever.  3 // Don’t react. Respond. Some feedback will sting. Some comments will be blunt. That’s okay. Never respond in anger. Walk away if you have to. Think. Reflect. Then respond with clarity and respect. Some of my biggest growth moments have come from pull requests where I was wrong, and someone cared enough to show me how to do it better. So here’s my advice: Treat code reviews as part of your learning loop.  That will make you a better teammate and a better engineer.

Code reviews aren't about finding bugs. If that's all you're doing in reviews, you've already lost. I've seen teams spend hours debating variable names and missing the actual problem: the code works, but nobody else can maintain it. Here's what code reviews actually catch: The junior engineer who hard-coded a feature that should be configurable. Not a bug. But you just locked yourself into technical debt that'll take 6 months to fix. The senior engineer who built something clever. Too clever. It works perfectly but breaks the moment someone else touches it. The architect who designed a system only they understand. No tests. No docs. Just "trust me, it works." Then they go on vacation and the system breaks. These aren't bugs. They're decisions that will hurt you later. Good code reviews ask different questions: • Can someone else debug this at 2am? • Will this still make sense in 6 months? • What happens when we scale 10x? • Are we building the right thing? Most teams optimize code reviews for finding syntax errors. Your IDE already does that. The real value is catching the decisions that look fine today but become disasters tomorrow. If your code reviews only find bugs, you're using them wrong. What's the worst "it works but..." code you've caught in review? #SoftwareEngineering #CodeReview #EngineeringLeadership

100 lines of code: reviewed in 10 minutes. 1000 lines of code: reviewed never. Code reviews exist to catch bugs, improve maintainability, and help teams write better software together. But most engineers treat them like assignments to pass instead of collaborative checkpoints. That mindset kills the process before it starts. ➧ When you're submitting a PR: 1. Keep it small Aim for 10-100 lines of code per pull request. Past 100 lines, reviewers start skimming. Past 500, they stop caring entirely. Large PRs are harder to review, take longer to approve, and make it nearly impossible to catch real bugs. Break your work into isolated, logical chunks. Yes, it's more work upfront. But it ships faster. 2. Write a description Give context. Always. Your reviewer might be on a different team, in a different timezone, or new to the codebase. Don't make them guess what you're solving. If you're fixing a bug, explain what broke and link to the ticket. If it's a visual change, add before/after screenshots. If you ran a script that generated code, paste the exact command you used. Context turns a confusing diff into a clear story. 3. Leave preemptive comments If part of your diff looks unrelated to the main logic, explain it before your reviewer asks. "Fixed a typing issue here while working on the main feature." "This file got reformatted by the linter, no logic changes." These small clarifications save back-and-forth and show you're thinking about the reviewer's experience. ➧ When you're reviewing a PR: 1. Be overwhelmingly clear Unclear comments leave people stuck. If you're making a suggestion but don't feel strongly, say it: "This could be cleaner, but use your judgment." If you're just asking a question, mark it: "Sanity check, is this intentional? Non-blocking, just curious." Over-communicate your intent. Especially with remote teams or people you don't know well. 2. Establish approval standards with your team Decide as a team when to approve vs. block a PR. At Amazon and now at Nielsen, we approve most PRs even with 10+ comments because we trust teammates to address feedback. The only exception: critical bugs that absolutely can't go to production. Without clear standards, people feel blocked by style comments and approvals feel arbitrary. Talk to your team. Set the rules. Stick to them. 3. Know when to go offline Some conversations don't belong in PR comments. If the code needs a major rewrite, if there's a design disagreement, or if you're about to write a paragraph, stop. Ping your teammate directly. Have a quick call. Save everyone time. Leave a comment like "Let's discuss this offline" so they know you're not ignoring it.

The best code review I ever received had zero technical feedback. Instead, my senior colleague wrote: "The code works perfectly, but someone reading this in 6 months won't understand the reasoning behind your approach. What context are we missing?" No nitpicks about variable names. No debates about algorithms. Just one simple question that changed how I think about code forever. That review taught me: → Code is written once, but read hundreds of times → Your biggest audience isn't your team today—it's your team in 6 months → Clarity beats cleverness every single time → The best code tells a story, not just executes logic Now when I review code, I ask different questions: "What story is this code telling?" "Will someone understand the 'why' behind these decisions?" "Are we solving for today's problem or tomorrow's maintenance?" The most impactful code reviews aren't about finding bugs—they're about building empathy for the humans who will inherit your work. What's the best non-technical feedback you've received on your code? #CodeReview #SoftwareEngineering #TechLeadership #CleanCode

People talk about code reviews like they’re quality gates but that’s a shallow way to see them. A code review isn’t just a searchlight for bugs. It’s a conversation. It’s a shared map of the system’s evolving shape. When you review a PR, you’re not just hunting for syntax errors or variable names. You’re uncovering the thought process that got us here. You’re seeing how someone else navigated ambiguity, trade offs, and a tight deadline. A good code review reads like a conversation in the margins: "Why did you choose this approach?" "What would happen if we flipped these two lines?" "Is this naming choice clear to someone who didn’t write it?" Code reviews that matter aren’t about power. They’re about empathy. They’re the moments when the most senior developer learns from the most junior one, and when the junior dev learns how the system thinks. It’s tempting to treat reviews as checklists lines of defense against mistakes but the truth is, they’re invitations to build shared knowledge. Because most of software engineering isn’t writing code. It’s writing together. It’s writing code that other people can pick up tomorrow, and understand not just how it works, but why it’s there at all. The next time you open a review, ask yourself: Am I checking boxes, or am I helping someone grow? Because every review is an opportunity, to build trust, to share context, to make the system, and the team, a little stronger. #SoftwareEngineering #CodeReviews #DevPhilosophy #TeamCulture #LearningTogether

Code reviews are about catching “evolvability defects” as much as bugs. When most teams think of code review, they think about spotting bugs. But here’s the reality: only 25% of issues flagged in reviews are actual bugs. The rest? They’re deeper problems that make a codebase harder to maintain and scale over time. These are what we call “evolvability defects.” Evolvability defects don’t crash your system today, but they lead to bottlenecks, tech debt, and friction that will cost your team down the line. Here’s a breakdown of what they look like: → 10% of issues are basic inconsistencies—alignment, spacing, structure. → 33-44% are documentation gaps—comments with missing context, unclear variable names, or lacking structure. → 44-55% are structural problems—inefficient organization, shortcuts that don’t scale, design choices that slow down future development. For developers, effective code review means more than finding bugs. It’s about ensuring code is readable, maintainable, and built to last. For engineering leaders, it’s about risk management. When code review prioritizes evolvability defects, your team’s velocity tomorrow is as strong as it is today. Is your team identifying evolvability defects? They’re what separate short-term fixes from long-term success. #codereview #bito #ai

Backend engineers who do great code reviews understand this ... The goal isn't to prove you're smart. It's to make the code better and help the team grow. That means: • Asking questions instead of making demands. • Explaining the "why" behind suggestions. • Celebrating good solutions, not just pointing out problems. Code reviews are where teams get stronger: • Junior engineers learn patterns. • Everyone catches mistakes before production. • Knowledge spreads beyond individual silos. Don't review code to gatekeep. Review code to elevate everyone.