Models for Collaboration
This past winter term, I completed CPSC 320: Intermediate Data Structures and Algorithms and, upon writing my customary reflection after finals ended, I began to notice how smoothly my group work in the course went. CPSC 320 had biweekly (i.e. fortnightly, not semiweekly) problem sets that could be worked on alone or in groups of up to three students. It was recommended, but not mandated, that we work in pairs, so I partnered with a fellow CPSC 110 teaching assistant (and a very old friend) for all five assignments. When collaborating on the homework, we adopted a workflow that, upon further discussion with our peers, turned out to be somewhat abnormal, albeit highly effective.
The workflow that I would deem the “classic model” for group homework assignments consists of the group members dividing up the problems between themselves and solving them independently, essentially reducing one homework set into two or more. There are three major flaws with this model. First, it is seldom possible to divide up the workload perfectly, even if you make the unrealistic assumption that a question’s difficulty can be objectively determined. Some questions may be harder than others and some partners may rate certain problems’ difficulties asymmetrically. This makes it easy for one partner (or multiple) to resent a real or perceived gap in effort among his or her fellow group members. Second, even if it were possible for a group to perfectly balance the assigned questions, those questions were likely assigned for a reason. When homework is divided up like this, important content can easily be missed, which can come back to bite on exams. Finally, since this model often involves hastily combining the partners’ individual contributions with minimal work to edit them, it can easily result in subpar marks with one person clearly at fault. This can easily reduce group cohesion in the future.
Another common model for collaboration is simply doing the entire assignment together. This obviously rectifies any inequalities resulting from splitting the work, but it also completely eliminates most of the advantages of working in a group. A group working together for the entire assignment is essentially just solo work with group members cross-checking each other, and with drastically limited meeting times. My partner and I were both very busy people, and I would dare say that neither of us strictly needed the other to get hundreds on each of the assignments. Because of this, we based our approach on the more conventional model of splitting the workload, with some caveats.
Our workflow for collaborating on homework had three main principles, each of which roughly corresponded to a phase of our process. Our goals were threefold: to reduce our workloads, to miss as few learning opportunities as possible, and to ensure that our individual standards for quality were satisfied.
The first principle of the strategy we adopted was that any learning in the homework assignment should be serialized. That is, we had to ensure that any key content was experienced by both of us, simultaneously, so we could both have the experience of actively thinking about and solving each problem. To accomplish this, my partner and I would either meet in person or call over Zoom the night after each homework assignment was released. During these meetings, we worked through the entire assignment together, looking to find the key insights for each question and note them down for later. We took notes and screenshots of these “sketches” of the proofs and algorithms we would later write.
Second, we sought to parallelize the “grunt work” of writing proper pseudocode and formal proofs for all of our sketches from earlier. At the end of our calls, we divided the assignment between ourselves, taking into account our relative proficiencies and the difficulty of each problem. Over the next week, we would separately make contributions to a shared LaTeX document, steadily completing the assignment.
The third and most important principle of our workflow was to share full accountability for all the work we submitted jointly. We achieved this by thoroughly examining our entire solution and ensuring that everything was up to both of our standards. We made changes as needed to ensure that we were both comfortable with what we were about to hand in and implicitly agreed that, if we lost marks on anything, the fault would lie with both of us, not just the original author of the error.
I’m under no delusion that this is a particularly deep insight. Indeed, I’ve practiced variations of it for my entire university career. That said, I decided it was worth a quick write-up after participating in many redundant conversations about the supposed incompatibility between group work and learning from homework, or between group work and getting a good mark. With a rather simple change in workflow, I found that they are quite compatible. By serializing learning, parallelizing grunt work, and sharing accountability, virtually all of the usual issues with group problem sets can be made to vanish.
