On the surface, the idea of code review is a no-brainer: why *wouldn't* we want a second set of eyes on our code, especially before deploying to production? As we peel back the layers, however, we find that the topic of code review is much more nuanced. How detailed should the review be? Who is qualified to perform the review (hint: it's not just senior developers)? Can we afford to take another developer away from their project to review this one? What steps can we take to ensure reviews are constructive, rather than demoralizing? Attendees will gain deeper insight into some of the arguments for and against systemic, peer code review, as well as pick up some useful tools to make code review a natural part of their teams' workflow.


Comments are closed.

Cory Jackson at 10:26 on 15 Nov 2018

Really enjoyed the talk. Lots of information to take back to the office.

Bobby Pearson at 22:12 on 22 Nov 2018

The speaker highlighted the importance of soft skills within the code review process: humility, collaboration, recognizing that any dev can benefit from reviewing any other dev's code. I'm going to do better with making "atomic" commits and also looking at the full commit history of a pull request to better understand the other dev's thought process.

This talk was probably equally useful for dev teams with a review process already in place as well as for teams without any review process at all. Well done!