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

Comments are closed.

Great talk! Nice work fitting all that info in the short time slot.

Great talk, somewhat amazing amount of info for a 25 minute slot. Only reason I give 4 instead of 5 is that Steve's verbal examples seemed to conflict significantly with the content of the slides. In particular, he used a lot of direct "you/you're" examples that were bordering on accusatory ("you're just wrong" or something to that effect). I think Steve was being casual and "real world" but especially in light of the preceding talk (The Monster on the Project) I experienced some cognitive dissonance during Steve's talk.