I don't want to give you the impression I'm not too fond of code reviews. I think they're one of the best ways to help developers improve their craft.

But I think there's one piece to the puzzle that is devaluing code reviews, and I want to share my thoughts on fixing it.

The big problem is...

Required effort for significant changes

Because code reviews are done at the end of the development cycle, after the developer has already invested a ton of effort and soul into writing his masterpiece (too dramatic? :) I know... but I couldn't resist) then comes the dreaded feedback.

The key word here: dreaded.

It's not that the feedback isn't helpful, but the process has split the parties involved into two opposite sides.

On one side, you have the author, who is quite invested in his work. And on the other side, you have one or more developers that are not at all invested but are usually well-intentioned and willing to help with whatever they can.

And when I say whatever they can, I mean pointing fingers at the flaws in the author's pull request. You can see how that might create a few problems.

It doesn't matter that much at this point if the feedback the author receives is "oh cool, but do you know you can rewrite this as ...", or "this approach is flawed, and we should rewrite everything", or "we already have this logic, why did you have to re-invent the wheel".

No one wants to hear any of it. That's for sure.

In many cases, (especially junior) developers get scared to ask for code reviews.

But why!? Why are we not receptive to valuable feedback? After all, the point is to ship the best possible work that we can. Right?

Wrong! It's not about shipping quality; it's about shipping something, anything so that we don't look bad to our boss.

That is the problem.

It's the pressure we feel when too much time goes by, and we haven't shipped anything. It makes us feel unproductive. It makes us feel like frauds because we have this foolish need to justify the time we spend working.

It's stupid. But it's true.

I don't care if you're working for the friendliest boss in the world or the most demanding. I can tell you for sure that the pressure to ship something is there.

And when the pressure is on, guess who's going to suffer in the end?

It's the code quality (and thus the company) because the codebase will inevitably become an unmaintainable blob.

People want to be seen as valuable contributors to the company's well-being. They want to feel accepted and valued. And your code review is getting in the way of it.

So how do we get out of this mess? How do we fix code reviews?

Fix your code review process

I want to share with you two ideas on how to improve your code review process and ultimately provide the learning aid that code reviews are great for.

There are at least two things you can do.

Plan ahead

Before any coding begins, you can do a design review meeting where you can put at least one senior developer in the room to either make the plan or at least validate it.

As a side note, if you're doing Behavior-Driven Development (BDD), this design review meeting comes baked into the process.

This way, you never start working on something that is fundamentally flawed from the beginning.

And that means that at the end of the development cycle (aka. code review time), you will never have to make big changes to your code or completely undo your work.

Since the direction was set from the beginning, it's really hard to mess up.

Add more skin to the game

Ideally, you would have the reviewers either write code or at least do pairing sessions with the author to course-correct and participate in the feature development.

When you add more skin to the game, the feedback is more valuable and feels less personal.

The author knows that those involved in the code reviews are aligned on the same goals, and they are also able to give more meaningful feedback. Simply because now everyone knows what the context is.

With no context, code reviews are more focused on syntax, best practices, with the occasional valuable insight.

But with context, code reviews tend to revolve around important aspects like performance, correctness, and quality.

Conclusion

I wouldn't give up on code reviews. On the contrary, I would make the most of what they are good at (helping others improve their coding skills) by implementing the two suggestions I mentioned.