Group Code Reviews
When it comes to code reviews I agree with others that pair programming is the way to go and when not practical using pull requests. There’s one more thing I like to do which I’ve used successfully at 2 companies now.
Every week, usually on Friday afternoon we have a meeting. Now before I go any further, I try to avoid meetings for the team as much as possible. Having said that, every Friday (usually in the afternoon) we have a “Code Review” meeting.
Why do it
The purpose of the meeting is for developers to present code that they’ve written or come across that is useful to communicate to the team. It could be a new pattern, a code smell identified or a unit test speed improvement. Its not uncommon for the developer to show before and after. Sometimes there’s discussion. Sometimes new stories are identified.
What do we talk about
During the week its common for there to be conversation and for someone to say…”oh that’s interesting, you should do a code review on it”. The message there is good work, lets make it a practice/pattern and communicate to the team. Another message is: this is important you NEED to tell others.
Developers attend the meeting with laptops and switch off presenting/demoing. Typically no one stands up when presenting. The format is fast paced and light (no powerpoints). Sometimes more junior engineers feel very intimidated to present to the group but I strongly encourage (require) them to do it. When I hire engineers I prepare them and let them know that I view communication as one of the most important skills that they will hone during their time with us. So yeah, you’re going to be presenting your ideas. I’ve found that with a little encouragement and positive reinforcement by the whole team, even the most shy of developers will get better presenting.
After code review we usually break and some engineers stick around and finish the day in the coding in the room, sometimes with music, beers, etc. Its a great way to end the week.
I didn’t come up with this on my own, much thanks to Ben Willis, Sevag Frankian, Brett Fishman and really all the amazing engineers that I’ve worked with.