Code reviews 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, 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. It provides experts with a channel to pass their domain-specific knowledge onto novices ... knowledge that can't easily be captured in a textbook or instruction manual.
Since I've now returned to academia, I've been thinking a lot about how to adapt best practices from industry into my research and teaching. I've been spending the past year as a postdoc in Rob Miller's group at MIT CSAIL and witnessed him deploying some ideas along these lines. For instance, one of his research group's projects, Caesar, scales up code review to classes of a few hundred students.
In this article, I want to describe a lightweight method that Rob developed for real-time, small-group code reviews in an educational setting. I can't claim any credit for this idea; I'm just the messenger :)
Imagine you're a professor training a group of students to get up-to-speed on specific programming skills for their research or class projects.
Ideally, you'd spend lots of one-on-one time with each student, but obviously that doesn't scale. You could also pair them up with senior grad students or postdocs as mentors, but that still doesn't scale well. And you now need to keep both mentors and mentees motivated enough to schedule regular meetings with one another.
Here's another approach that Rob has been trying: Use regular group meeting times, where everyone is present anyways, to do real-time, small-group code reviews. Here's the basic protocol for a 30-minute session:
That's it! It's such a simple, lightweight activity. But it's 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. But at the same time, it isn't large enough for students feel anonymous and tune out like they would in a classroom. Since everyone sees who else is commenting on the code, there's 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 that 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's 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 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. But here, reviews are purely formative so students understand that they won't be "graded" on it. Rather, they understand that the activity is being done purely for their own educational benefit.
When running this activity, you might hit the following snags:
Try running some real-time code reviews at your next group or class meeting.
No entries found