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.