A code review is not like watching a football match

In my experience a code review must have a goal. Some common goals are:

  • Telling others how you solved a common problem.
  • Warning others about certain perils (i.e race conditions, coupling...)
  • Asking concrete questions. Implementation or design questions.

When you expose some code to your colleagues in a meeting room, you should know exactly what you want to get from that activity. You want to learn, to tech or to warn others basically. Otherwise, if you just open up some code and ask your colleagues what's their opinion about the code, then everyone will say something. Exactly like watching a football match with friends, everyone has his/her opinion on how the coach should manage the team, how players should play... no matter how good the team play, there will be always someone opinionated bullshit. The code review will be frustrating and not very productive.

Remember to prepare a list of questions or tips to tell others, together with the code you want to share, before going to the code review.

  • pedrofraca

    Hi Carlos! first of all, great article!

    Did you perform this practice with all the tasks your team is implementing? or just with the complex ones? At some point I fell that in our team we don’t pay the attention to the code review needs, we do it quickly to move forward the ticket to next phase to keey team velocity. But this year we want to do more focus on this practice and grow as a team.


  • http://www.carlosble.com/ Carlos Ble

    Hi Pedro! We pair most of the time and we mob (mob programming) several times a week. We definitely see a lot of value in the immediate feedback and synergy that people create working together on the same task. We run code reviews once a week.