Estimated reading time: 6 minutes
It all starts and ends with establishing a good code review culture.
Code reviews are intended to improve our coding skills, identify risks early, and foster learning from one another. In best-case scenarios, they raise the overall quality of the product and help teams move faster with confidence. At the worst, they create frustration, slow everything down, and undermine trust.
Coming from QA into engineering management, I have seen how reviews that drag on for days over trivial things can affect morale.
One of the reasons I started creating shared review guides for my teams was that I had been through reviews that felt like battles, where comments were abrupt, nitpicky, and left PRs frozen for days. As a result, I began by sharing examples of constructive feedback and facilitating a team conversation about what kind of review culture we actually wanted. Out of that, we shaped our principles, created a simple set of expectations, and built accountability around them.
When code reviews hurt more than help
We have all been there. A pull request (PR) is ready to go, but it stalls for days over a debate about “tabs vs. spaces”. Or worse, a teammate leaves vague comments like “this looks wrong” with no explanation. And, sometimes, the feedback arrives so late that the author has already moved on and lost all context. On top of all this, inconsistent reviewing styles – where one reviewer’s version of fine is another’s dealbreaker – can kill productivity. This is particularly true for new team members, who will be stuck guessing preferences instead of actually learning.
These behaviors might seem minor, but they have a huge impact. People no longer trust each other, and open collaboration becomes a myth. It doesn’t take long before people start working around the process, sending PRs only to the “easy” reviewers, or worse, merging without a proper review just to avoid the hassle.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
Code review pitfalls to avoid
While it’s almost too easy to be aware of wider team-level trends that add to a bad review culture, there are some personal habits engineers should look out for:
- Nitpicking over substance: pointing out minor syntax choices or trivial formatting issues (that linters already catch) only slows people down. I once had a report who constantly requested unnecessary PR changes that didn’t improve the code itself, only created tension and wasted time.
- Blocking merges without explaining why: a flat “no” without context does not help anyone. If something is really a blocker, the reviewer should be able to explain the reasoning behind it.
- Being inconsistent: reviewing thoroughly one day and barely skimming on the next one creates confusion. Developers don’t know what is expected, so they second-guess themselves.
- Gatekeeping instead of collaborating: when reviewers act as the final authority on what gets merged, reviews turn into checkpoints to pass. However, they should be a conversation meant to move work forward and learning along the way.
How to build a strong team code review culture
Code reviews aren’t just about catching mistakes. They are also about how knowledge is shared and how to hold each other accountable. In a healthy review culture:
- Developers feel safe asking questions or making mistakes.
- Reviewers focus on improvements that actually matter.
- Everyone knows what “good enough” looks like.
The good news is that to achieve this, you don’t need a massive process. A few intentional practices can completely change how reviews feel and what they deliver.
More like this
1. Define what “good” looks like
Without shared expectations, reviews will always feel subjective. Every team should take the time to agree on what matters most in a review: clarity, maintainability, test coverage, security, performance, and so on. This should not hinge on personal coding styles.
On my teams, I always try to have the team come together to create a shared document highlighting best practices for code reviews (e.g., verify feature requirements, assess readability, etc.) with a set of informal “PR etiquette” rules. This will explain how to give feedback, avoid nitpicking, and clarify the distinction between a blocker vs. a suggestion.
This kind of shared document helps everyone stay aligned and gives new teammates something concrete to lean on.
2. Balance thoroughness with speed
Slow reviews are a productivity killer. I usually set an expectation with the team about how long PRs should take to be reviewed (e.g., within one business day), and I encourage them to respect that. On the other side, authors should also keep PRs focused and reviewable. Smaller PRs are easier to understand, easier to give good feedback on, and faster to merge. And if there is no way to avoid a large PR, use that situation to promote a mob review. It will be a moment for team bonding and collaboration.
If having stalled PRs is a recurring issue, I’ve also seen value in rotating review buddies – developers assigned to review new PRs – or scheduling a “review hour”, where the whole team pauses and clears out the queue together.
3. Promote early feedback
Too often, feedback on code comes once the work is done, which leads to rework, frustration, and delays. To remedy this, encourage people to share design ideas, partial implementations, or even just a “thinking out loud” summary before the full code is written. It doesn’t need to be something very formal; it can simply be mentioned during stand-ups or even shared in Slack channels.
Early feedback can happen through:
- A quick pair programming session.
- A design review doc.
- Opening a draft PR.
This way, big concerns get spotted early, and authors don’t feel like they wasted hours or days writing code that gets rejected at the end.
4. Coach on feedback quality
Good feedback is a skill. Some people are naturally better at it, but anyone can improve. The way feedback is framed makes a huge difference. I try to model this myself by:
- Framing comments as suggestions: “What do you think about…?” instead of “You should…”
- Asking questions before assuming: “Could you walk me through your approach?”
- Calling out the positives, not just the negatives.
If you lead a team, consider keeping an eye on how reviews are happening and paying attention to discussions around a PR. Not to micromanage, but to spot patterns, and then coach them on how to improve. The key is to stay at the team level, looking for recurring topics like delayed feedback, overly harsh comments, or unclear expectations, rather than focusing on individual mistakes. When something stands out, try to bring it up in retros or 1:1s as a conversation starter, not a correction. That way, you avoid the feeling that you are hovering over every PR, while helping the team reflect on how reviews are going and encouraging growth.
November 3 & 4, 2025
Book now and save up to €250 💸
Final thoughts
Code reviews are one of the most powerful tools we have, not just for improving code and quality, but for building stronger teams. However, they only work if we treat them as collaborative and respectful.
As leaders, we set the tone. If we reward clarity instead of cleverness, curiosity instead of control, and growth instead of ego, reviews can shift from being a source of friction to a real driver of impact.
From nitpicks to impact, that’s a culture shift worth investing in.
