Code Review or Pair Programming?

I've been taking a few programming courses on Coursera lately. In case you're not familiar with Coursera, it allows tens of thousands of people to simultaneously take university-level courses for free (on-line, of course).

In particular, I've been learning programming language R and its application in machine learning. Naturally, there are a number of programming exercises used to enforce student's learning by allowing the theory from the lectures to meet the reality of actual code. Most of them provide immediate feedback by running fully automated tests against the student's code. However, there are a few that rely on peer review.

At first, I was quite skeptical of the idea that students, who are still learning the subject matter, are asked to grade and provide feedback on other students' work. Usually that's job for the experts, e.g., University's teaching assistants. Plus, from my experience in software industry, peer reviews are typically very bureaucratic and adding very little value, in other words: waste of time.

As I went through several rounds of peer reviews, both reviewing other people's work, as well as reading other people's feedback on my own work, I started realizing I had been completely mistaken. It turns out that the opportunity to review other people's solution to the same problem that I had already independently solved is actually an opportunity to learn and connect the dots that may have been left unconnected by simply listening to the lectures and doing my homework and practical exercises my own.

How come, I wondered, that this peer review mechanism works so well in the global, massive on-line open learning environment, and utterly fails to deliver value in the software engineering workplace? Then it dawned on me: what the students are doing in Coursera in the form of peer reviews is actually much closer to pair programming than peer reviews in the workplace!

The key constraint in Coursera is that peer reviewers are only allowed to review their peers' work after they submit their own work for review. That means they are already intimately familiar with the problem at hand, as well as at least one solution to that problem. This pre-condition enables the reviewer to easily understand the intricacies of individual approach, recognize important differences, and then ultimately benefit in the exchange of ideas and experiences that ensues.

When one compares this process to the typical peer review process in the workplace where reviewers are typically neither familiar with the problem being solved, nor with the solution space, it becomes clear that Coursera's peer review is actually a surrogate pair programming practice, merely compensating spatial and temporal distances of the global learning community.