Item — HN Reader

Honestly, in my opinion, the fact that this type of thing can even happen suggests the format of code-review has a problem. I propose it's better to:

1. Sit at the desk of the person and pair-code review. Helps avoid basic misunderstadnings, and also is more private that a permanent written record where people may feel defensive about their choices. Also it's easier for a lot of people to be rude through the internet.

2. Write in small notes if any must-address concerns arise and are agreed-upon (e.g. "Security?", "duplicates function x")

If your devs can't interact face-to-face, then I think you've got major cultural problems or hired the wrong devs.

3 comments

Agreed. Pair reviewing is great. Especially with people you don’t know that well. Once you know each other and trust each other the traditional review tools work better.

Code review is like any other interaction pattern that happens asynchronously. Many teams work this way. Remote teams, teams with people on different time zones, open source projects (what this article seems to be geared towards), etc. Face-to-Face interaction isn’t always possible, and that’s why the advice like the article’s is useful.

Or you're working on an open source project.

Maybe a shared-screen video call, then? Same for non-colocated colleagues.

This makes it much harder for people to review stuff since they'll need to schedule for such reviews. Normally reviews happen asynchronously whenever people find time and often code review tools allow for writing a review piece-by-piece (that is, your progress is saved on the server that hosts the review) instead of all-in-one.

Introducing any form of friction makes reviews less desirable for everyone involved.

Agreed. But for complicated reviews, a high-bandwidth synchronous meeting can be useful. Perhaps start out asynchronous, with the reviewer requesting a live meeting/call if they feel it's necessary? That's always worked well for me.

Or whoever reviews your code is in a different city.