How Code Reviews are like Being in a Relationship

I’ve only been doing code reviews for a few months, but it seems to me that there are some similarities between doing them and being in a relationship, namely:

  • Picking your battles. From time to time, you’ll see a snippet of code that you may not like; perhaps it breaks from the standard format that you’re used to seeing everywhere else, or maybe it’s just a one-liner that isn’t particularly readable but that is so minor that it doesn’t matter much in the grand scheme of things. Even though it’s probably not code that you yourself would ever write, this is usually the time to ask how big of a deal it really is. If it’s a good chunk of logic that is clearly going to be difficult to maintain, or will need to be re-used elsewhere and should be moved to a shared module, then you’re going to want to raise a red flag and work together to make it better.I’ll admit though that, just like being in a relationship, it can be a struggle to know which battles to pick. Sometimes you may find yourself questioning something, and then quickly realize that the amount of time it’s taking to discuss it back and forth isn’t justifiable and that it’s better to just let it go.
  • Letting your partner have their own personal style. I actually find this rule somewhat difficult to follow. The line between personal style and good coding convention is a fine one. At the same time, programming is an art, and no two people would write the same piece of code in exactly the same way. In the end, if it’s readable, maintainable, efficient, and it follows whatever style guide you’ve adopted, then that’s usually good enough.

Code Reviews – The Good Parts

One of the best things that I’ve found about doing code reviews (besides forcing you to be accountable for your work) is that you often see certain techniques or conventions being used that you yourself then begin to apply to your own code. It’s this collective knowledge that helps to make the software better. Don’t be that guy who argues against constructive criticism until everyone’s blue in the face, or cries in a corner when someone else points out your mistake. Yes, your ego may take a beating. And yes, you may feel foolish for not having spotted that flaw in your code before someone else did, but in the end, the code will be better and so will you.

What rules do you follow when performing code reviews? Are they fairly strict or more flexible?