June 19, 2014
Code reviews (http://bit.ly/Ve4Hbw) are essential in professional software development. When I worked at Google, every line of code I wrote had to be reviewed by several experienced colleagues before getting committed into the central code repository. The primary stated benefit of code review in industry is improving software quality (http://bit.ly/1kvYv4q), but an important secondary benefit is education. Code reviews teach programmers how to write elegant and idiomatic code using a particular language, library, or framework within their given organization. They provide experts with a channel to pass their domain-specific knowledge onto novices; knowledge that cannot easily be captured in a textbook or instruction manual.
Since I have now returned to academia, I have been thinking a lot about how to adapt best practices from industry (http://bit.ly/1iPU31a) into my research and teaching. I have been spending the past year as a postdoc (http://bit.ly/1qRnowt) in Rob Miller's (http://bit.ly/1mKQybj) group at the Massachusetts Institute of Technology Computer Science and Artificial Intelligence Laboratory (MIT CSAIL, http://www.csail.mit.edu/) and witnessed him deploying some ideas along these lines. For instance, one of his research group's projects, Caesar (http://bit.ly/1o9AXVg), scales up code review to classes of a few hundred students.
In this article, I describe a lightweight method Miller developed for real-time, small-group code reviews in an educational setting. I cannot claim any credit for this idea; I am just the messenger.
Imagine you are a professor training a group of students to get up to speed on specific programming skills for their research or class projects.
Ideally, you would spend lots of one-on-one time with each student, but obviously that does not scale. You could also pair them up with senior grad students or postdocs as mentors, but that still does not scale well. Also, you now need to keep both mentors and mentees motivated enough to schedule regular meetings with one another.
Here is another approach Miller has been trying: use regular group meeting times, where everyone is present anyway, to do real-time, small-group code reviews. Here is the basic protocol for a 30-minute session:
That is it! It is such a simple, lightweight activity, but it has worked remarkably well so far for training undergraduate researchers in our group.
With a 4-to-1 student-to-facilitator ratio, this activity scales well in a research group or small project-based class. This group size is well-suited for serendipitous, semi-impromptu discussions and eliminates the intimidation factor of sitting one-on-one with a professor. At the same time, it is not large enough for students to feel anonymous and tune out like they would in a classroom. Since everyone sees who else is commenting on the code, there is some social pressure to participate, rather than zoning out.
A side benefit of holding regular code reviews is that it forces students to make consistent progress on their projects so they have new code to show during each session. This level of added accountability can keep momentum going strong on research projects since, unlike industry projects, there are no market-driven shipping goals to motivate daily progress. At the same time, it is important not to make this activity seem like a burdensome chore, since that might actually drain student motivation.
Industry code reviews are often asynchronous and offline, but ours happen in a real-time, face-to-face setting. This way, everyone can ask and answer clarifying questions on the spot. Everything happens within a concentrated 30-minute time span, so everyone maintains a shared context without getting distracted by other tasks.
Also, industry code reviews are often summative assessments (http://bit.ly/1z8kOH1) where your code can be accepted only if your peers give it a good enough "grade." This policy makes sense when everyone is contributing to the same production code base and wants to keep quality high. Here, reviews are purely formative (http://bit.ly/1jKElU6) so students understand they will not be "graded" on it. Rather, they understand the activity is being done purely for their own educational benefit.
When running this activity, you might hit the following snags:
Try running a real-time code review at your next group or class meeting, and email me at email@example.com with questions or suggestions.
©2014 ACM 0001-0782/14/09
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from firstname.lastname@example.org or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2014 ACM, Inc.
No entries found