
Humanizing Peer Reviews (2002) - kiyanwang
http://www.processimpact.com/articles/humanizing_reviews.html
======
mtlynch
I've been reading different articles about code reviews lately and I found it
strange that so many of them focus on the best ways to identify your
teammates' mistakes, but say very little about the exact means of
communicating that feedback. Having worked for several large software
companies, I think developers struggle much more with the latter than the
former.

I think this article describes what's important about code reviews better than
any other article I've seen.

A couple very nice quotes I think are worth highlighting:

>The best software engineers I have known actively sought out reviewers,
having learned early on how much they can help. Indeed, the input from many
reviewers over their careers was part of what made these developers the best
at what they do.

I've definitely found this to be true as well. I'm generally known on my teams
as a tough reviewer, so my favorite people to work with are people that seek
me out for reviews because they see it as an opportunity to learn.

>Egoless programming enables an author to step back and let others point out
places where improvement is needed... Similarly, the egoless reviewer should
have compassion and sensitivity for his colleagues, if only because their
roles will be reversed one day.

I liked this point as well. So many articles about code reviews completely
miss how significant a factor your relationship with your teammate is to a
code review. If you sour that relationship with accusatory, tactless feedback,
it doesn't matter how great a developer you are because your future code
reviews and interactions with that teammate will be tremendously weakened.

------
DamonHD
The last section about cross-border reviews hits home, though curiously my
biggest problems came with rather aggressive eastern Europeans in a UK
environment, having happily worked with US and Japanese and Hong Kong teams
before!

