How Weak Opinions Damage Code Review

Let’s talk about strong and weak opinions before jumping to how exactly they damage your code review. I just need some contrast here.

Consider this scenario:

Sofia is reviewing a new feature that Arthur has implemented. She notices similarities between some new functions and existing code in another module.

“We should get rid of this duplication,” she decides and requests changes with a comment.

Sofia’s stance is clear — she’s calling for action. Arthur might have his reasons for the duplication, or maybe Sofia has overlooked something and the code from another module isn’t that similar. Either way, this opens up a conversation to agree on the best course of action because in most teams, it would be considered inappropriate for Arthur to dismiss this comment and proceed with the merge.

Requesting a change or asking a question is a direct way to express a strong opinion. Anything that would require an action would do.

Now, consider a different situation:

Jack is looking over Arthur’s code and spots several functions doing the same thing. He sees potential for improvement but also knows Arthur has put a lot of effort into this feature, and it’s functioning well.

With this in mind, Jack approves the pull request but adds a note: “These functions seem similar; I would consider combining them.”

The key distinction here is Jack’s approach—he didn’t request changes; he approved the pull request and added a comment. He might think he’s pointed out a potential improvement, but in reality, he’s shifted a reviewer’s responsibility onto the author. Now, it’s up to Arthur what to do.

Arthur sees an approved pull request and some mumbling about what Jack would consider but at this point who really cares what Jack would consider. The feature is good to go and the change is approved.

This exemplifies what I call a weak opinion—a remark that doesn’t require action, allowing it to be easily disregarded. The reviewer feels good for offering input, and the author is free to proceed with the merge.

Obviously, there is always an option to withhold an opinion:

Marcus has finished reviewing Arthur’s code and feels uncertain. Could the code be better? Probably. But that’s true for most code, right?
Marcus thinks about leaving some comments but wonders if they’d be helpful. Arthur probably knows about those issues and chose not to fix them because of the tight deadline. Why bring up the obvious?

Thinking his input won’t add value, Marcus approves the change without comments.

Reviewers might hold back for various reasons, such as doubting their feedback will lead to positive change or assuming the author is already aware of the issues and made a conscious decision. However, this can be more detrimental as it deprives the author of potentially valuable insights that could help to improve the code.

To recap:

• A strong opinion requires an action and is difficult to overlook.
• A weak opinion merely provides information and can be ignored.
• A withheld opinion is the absence of feedback when a reviewer has something to contribute.

Roles in code review

In the code review process, we have two key roles: the author and the reviewer.

Their shared goal is to find the most suitable solution, but they approach it from different angles, which is precisely what adds value to code reviews.

The author is deeply familiar with the problem, its significance, constraints (including deadlines), and the code they’ve written. This deep involvement comes with certain risks:

• The author might prioritize the problem’s urgency over other aspects due to its recency and their personal responsibility for resolving it.
• Being so close to their own work, the author may struggle to evaluate the solution objectively.

A reviewer is supposed to be in a better position to balance things out because they aren’t familiar with this new code, not affected by the time spent deep in the solution mode, and probably less attached to the problem than to a pre-existing state of the system.

Challenge of being a reviewer

The role of a reviewer isn’t something that comes naturally to engineers. We’re wired to write code and solve problems – that’s our comfort zone, where we spend most of our time.

But were you ever taught how to review code? If so, you’re one of the lucky few. For most of us, code review just became another responsibility. The assumption was simple: if you can write code, you can surely comment on someone else’s. But it’s not that straightforward.

The difference between writing code and reviewing it is like the difference between playing the game and coaching. The game is the same, but the skills are different, and they need to be learned. Being a star player doesn’t automatically make you a great coach.

Therefore, reviewers often fall back into an author’s mindset.

What does an author want? A fast, smooth review, a second set of eyes to confirm everything’s okay, maybe a bug caught here or there. And that’s what they end up giving — quick checks instead of deep dives into the code that could reveal inefficiencies and provide constructive feedback to enhance both the codebase and the author’s skills.

Where weak opinions come in

From a reviewer's perspecitve, realizing the code could be improved and staying silent doesn’t feel right. Yet, it’s equally uncomfortable to ask a colleague to rework a substantial portion of their code or to dedicate additional time to address issues you’ve identified.

Leaving a non-blocking comment that points out the problem without demanding action might seem like a way to avoid difficult conversations.

However, this approach can be misleading — it makes you think you’ve contributed to enhancing the codebase when, in fact, you’ve passed the responsibility to the author. It’s a soft touch that can lead to hard issues down the line. True improvement comes from facing these challenges head-on, not from sidestepping them.

Strong yet supportive

Strong opinion does not mean harsh. This isn’t about tearing down code that doesn’t match up to your expectations. Your real mission is to foster positive change, not just to flag errors or show off your expertise.

A good piece of advice I once received was to assume missing important context.

It will be true more often than not because as a reviewer, you’re not privy to every detail of the author’s challenges, their objectives, or why they chose one path over another. And even if you think you’ve got the full picture, you can’t possibly know every solution out there to be certain your suggestion is the best and should be implemented.

That said, assuming missing important context it’s not just about acknowledging that you might not have all the answers — it’s also about showing that you’re open to learning and considering different approaches, not pushing for something you came up with.

Start with yourself

If you’re on the fence about making a comment, think about the ripple effect. What if every commit had the same issue?

Imagine every pull request with functions taking three screens, similar to the one you're approving right now. Or more of those clever bitwise operations. Or complex calculations with no tests to prove they're correct.

It might seem like an overstatement, but it’s the reality. We often mirror the style of the existing code for consistency. We copy-paste code blocks. We gauge what’s acceptable based on what’s made it through reviews before.

So, if you’re sure there’s room for improvement, don’t hold back — suggest an action and make it explicit. Sometimes, that action might just be a question for the author to explain their reasoning, which could sway your perspective.

Remember, not every comment has to lead to a change.

Help others

When you’re in the thick of a code review, you might spot weak opinions left by others.

In such cases, you can play a crucial role.

By adding your own insights and explicitly requesting an action, you can transform these weak opinions into strong, actionable items. Whether it’s through asking probing questions or even rejecting a pull request that someone else has approved, your input can significantly enhance the review process.

Interpret non-blocking comments to your code

Non-blocking comments are often seen as optional, merely providing information or sharing a reviewer’s thoughts.

But now you can see that’s not always the case. A comment like “by the way, this function you implemented already exists in the library we use” isn’t just a passing remark. It’s a hint from the reviewer aimed at preventing cluttering the codebase with redundant code.

When you come across such comments, consider the broader implications, similar to when you are the reviewer. If every commit introduced similar issues, how would that affect the codebase over time? Again – once a commit is merged, it becomes a part of the standard others will follow, potentially leading to a pattern that could be detrimental to the project’s health. So, treat these comments with the seriousness they deserve —t hey’re not just side notes; they’re signposts for maintaining standards.