I always thought of code reviews as a quality check but I realized that I have been doing them wrong. Here are a few loopholes I can see now with my previous understanding:

1. It's almost always late to address the bigger design problems in a code review and chances are you will let them go as technical debt because, of course, deadlines matter!
2. It's slow by design. Asynchronous collaboration on github or similar tools can take a lot of back and forth comments to communicate the essentials.
3. It's easier to run around in circles and waste time because understanding the code written by other people can be difficult. You might end up spending a lot of time discussing a point that doesn't lead anywhere.
4. It reduces the need and immediate importance of documentation as it's easy to ask and provide justifications via comments. However, what happens when someone reads it again after six months and they are looking for same answers?

These aren't necessarily flaws of code reviews as a tool itself but the consequences of fitting code reviews in every situation. Over relying on code reviews as a quality tool can potentially create more problems than it solves.

How to make it more humane and better?

In my experience it works better if I think of code reviews as a tool for asynchronous collaboration. This helps me focus more on the human aspects of code review and optimize better for my team mates.

As an Author

1. I can make a judgement if I am better off taking a peer on the call and pair program instead of just raising a PR like I am doing a favor to them. The good ol' pair programming is never out of fashion! 🤓
2. If something is complex to design, I can share my ideas with peers before implementation and get feedback before going down the rabbit hole. 🕳
3. I can write better descriptions to help my peers understand the code in lesser time. 🚀
4. I can predict better and leave comments at the places where reviewers will ask question. For instance, justifying a decision involving tradeoffs. 🧐
5. I can ensure that I am not surprising my teammates with the closet ghosts by communicating early and often. 👻
6. I can reduce the cognitive effort of my peers to review the code which leads to timely and better feedback. ⏳

As a Reviewer

1. I can prioritize reviews to unblock my team mates. 🚦
2. I can review in one go so that author isn't annoyed by comments. Github review functionality is a life saver. 🚑
3. If I find something confusing, i can reach the author directly and clear the air using faster communication channels such as slack or a live call. 🏃🏾‍♂️
4. I can give headsup to team mates if I know they are working on something complex and they can use my knowledge.💡

I still need to formally ask my teammates but I think if I am being this considerate of them, they must love ❤️ working with me. 😀

PS this is not another post on how to do code reviews or how to make good PRs. Of course, there is a lot of other stuff you need to consider but you can find a lot of content on those topics at tons of other places. I just wanted to highlight the often underrated but humane aspect of code reviews.