As an experimental elementary particle physicist in the 1970’s I was lucky enough to work on what turned out to be one of the most important physics experiments in the second half of the twentieth century. Exploring the rare interactions of neutrinos in a huge bubble chamber at CERN, the European laboratory for particle physics, required labs in five countries to view and hand-digitize millions of filmed particle tracks projected onto large white tables. Only a few of these images were expected to show the crucial events we were looking for, so it was important that we didn’t miss anything important.
When you’re staring at hundreds of similar images, one after the other, for hours on end it’s easy to overlook something. So how did we minimize the chance of missing an infrequent crucial particle interaction?
The answer is surprisingly simple. Every set of film images was scanned at least twice on separate occasions by different staff. The resulting set of information on each image was then checked to see if all the viewers agreed on what was going on. If they didn’t, other staff viewed the film again to discover who was right, thus catching missing information or interpretative errors. Statistical methods then allowed us to calculate how accurate each scan operator was, and even to predict the small likelihood that all viewers would miss something significant.
This approach allowed us to be confident of our ability to catch a few, very important particle interactions. The best evidence for our results—which provided the first confirmation that a Nobel Prize winning theory unifying two fundamental forces in nature was indeed correct—was based on finding just three examples.
Another example of how people working together can create more reliable work is pair programming: a technique that became popular in the 1990’s for developing higher quality software. In pair programming, two programmers work together at one computer. One writes code while the other reviews the code as it is typed in, checking for errors and suggesting improvements. The two programmers switch roles frequently. Pair programming typically reduces coding errors, which are generally difficult and expensive to fix at a later stage, at the cost, sometimes, of an increase in programmer hours. Many software companies creating complex software find that the value of the increased quality is well worth any additional cost.
While these two examples of cooperative work concentrate on reducing critical mistakes, it doesn’t take much of a leap to see that working together on a learning task may increase the accuracy and completeness of what is learned. As a bonus, the two (or more) learners involved receive an opportunity to get to know each other while they share an experience together. With the right design, there is little downside but much to be gained from learning with others rather than alone.