1. 11

  2. 7

    Use “we” instead of “you”. This is a team effort after all. I try not to make the comment sound like I’m pointing fingers and playing the blame game.

    This is really, really important. If you’re in an organization of more than 1 person, there’s no individual “ownership” of the code. It has to be owned collaboratively and collectively. Ensuring that the tone of the review is collaborative, not hostile is very important in promoting a healthy environment.

    Aside: I had assumed that the venerable Dan Luu had just gotten a new domain, as this seems like a likely post by him, but this was in fact written by Steven Luu.

    1. 4

      Further to this, I go out of my way to make sure I talk about the code as a seperate entity from the people who are submitting it.

      Instead of saying, “You shouldn’t do this here” I say, “This is a problem” or something to that effect. That is, I point out that there is some deficiency in the code and don’t directly associate it with the person who wrote it.

      I find this is a bit of an uphill battle because it’s so easy to use personal pronouns. I get in conversations about code and find myself assigning ownership because everyone else is doing it. I do my best to correct myself as much as I can, and make a point of making sure others notice I’m rephrasing by removing the “you”.

    2. 4

      Code reviews should be foremost a check on functionality, performance, readability, maintainability and security. Does it do the thing correctly and safely without breaking anything else? Can I reason about it without having to ask you how it works? Beyond that, most contributions are just pedantry.

      Code reviewing is a fantastic tool for preventing bugs; indeed, probably the best tool we have. Unfortunately, as a professional practice, it also tends to attract fussbudgets, pedants, and people trying to arrogate authority and have time-consuming, asynchronous philosophical debates about stuff that doesn’t help move the project forward.

      1. 2

        At the most recent PyCon there was a good presentation entitled “Constructive Code Review”: http://pyvideo.org/pycon-us-2017/constructive-code-review.html