5 ms·
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
by alexandercrohde 7y ago
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.
- smcameron 7y agoOr you're working on an open source project.
- organsnyder 7y agoMaybe a shared-screen video call, then? Same for non-colocated colleagues.
- Crinus 7y agoThis 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.
- organsnyder 7y agoAgreed. 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.
- Crinus 7y agoOr whoever reviews your code is in a different city.
- Ididntdothis 7y agoAgreed. 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.
- turdnagel 7y agoCode 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.