Two’s Better Than One

FRIEDA and GEORGE were quite happy to program on their own during in-class coding activities. The problem was that when either of them got stuck on a bug or at a place where they had a concept gap, they remained there until I stopped by during my rounds. They wouldn’t ask for help for fear that they’d be seen as the only ones with an issue. I’d been trying to find an elegant solution to this problem. Onthe-noobe that’s more scalable than my walking around frenetically to find out who was stuck and who wasn’t. That’s when I realized that Elaine Haight’s pair programming suggestion would work wonders in this situation.

In a previous post, I alluded to my implementation of a pair programming strategy in class to enhance the learning experience. A large body of research supports the idea of pair programming, linking with it both improved productivity and enhanced learning. Williams and Kessler provide a thorough discussion of the topic in their very readable book [1].

Briefly, the idea is to get students to program in pairs, with one student calling out the code and the other simply typing it in. The student typing in the code is called the driver and the person calling the code to be typed is called the navigator. Although Williams and Kessler offer several arrangements, I preferred to use an arrangement with exactly one keyboard/mouse and one monitor. The driver sits squarely in front of the keyboard and monitor and the navigator sits nearby with a clear view of the screen.

Overall, my experience with implementing pair programming has been productive thus far, as measured by both student feedback and the scores they’re receiving on their homework assignments. In a pair, I found that students:

  • Felt a lot more confident about their own abilities
  • Didn’t feel stressed or anxious about the possibility that they’d get stuck without making progress
  • Didn’t feel an overwhelmingly unproductive/paralyzing sense of responsibility for the end-product
  • Felt significantly bolder when it came to taking risks (essential for creative experimentation) because of the perception that a second pair of eyes would keep them from making catastrophic errors.

I also found rather quickly that pair programming needs to be implemented carefully. Otherwise, the driver often tends to take the back seat and lets the navigator do all the coding, simply becoming a conduit for the expression of the navigator’s stream of thoughts on the screen. Likewise, navigators were quick to realize that though they were programming, as it were, in a pair, in reality, they were really coding alone with the attendant loss of all the benefits I listed above. It is, however, easy to avoid this pitfall by implementing some simple ground-rules:

  • Students must switch roles periodically. I originally had them switch roles at functionally determined transition points. For instance, student A would navigate for the implementation of a particular method, class or module, student B for the next one, and so on. But it became clear that this strategy encouraged the tendency to mentally disengage from the task while they were driving since they’d start on an effectively new task when they took over as navigator. Elaine suggested that a better approach would be to trigger rotation on a timer. With timed rotation, students switch roles at predetermined intervals rather than after each functional unit. Timed rotation also meant that each student would have to stay in mental step with whatever the other student was doing – The timer would run out unpredictably. They’d have to take over any time and hit the ground running. To facilitate this, I hacked up a trivial web page during the first couple of minutes of class a few weeks ago. After establishing that the strategy worked, I moved the page to Feel free to use it if you want. I’ll polish it up with a better skin and variable interval if there’s sufficient interest.
  • Students must go with the flow: No drastic design changes should be introduced. This has the dual benefit of teaching students to work effectively in a team by rapidly adapting to another programmer’s viewpoint, and shepherding the team project to completion within an allotted time. If teams were allowed to change direction willy nilly, they often meander about without a strong sense of direction.
  • Students must physically trade places upon rotation, which involves getting up and moving, rather than shifting the keyboard and display. I find that physical relocation of coding agents is more conducive to mental readjustment when students must adapt rapidly to new roles.

I also provide scaffolding and guidance by simultaneously coding parts of the project on the big screen in front of the class (with a number of carefully selected TODO sections, of course) – This keeps the various groups aligned and approximately in step with each other.

PairProgDilbertFinally, I sweeten the deal by turning the whole classroom exercise into a kind of low-stress game/race by offering Extra Credit (ECBux) to the first group to complete the assigned project and present it on the big screen in front of the class. Thus every lecture turns out to be a group activity and a game that students seem to look forward to.



[1] Laurie Williams and Robert Kessler. 2002. Pair Programming Illuminated. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.


About andatfoothill

I teach at Foothill
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s