TITLE: Pair Programming is a Skill to be Learned
AUTHOR: Eugene Wallingford
DATE: May 03, 2016  4:19 PM
DESC: 
-----
BODY:
David Andersen offers a rather thorough list of ways that
academics might
<A HREF="http://da-data.blogspot.com/2016/04/stealing-googles-coding-practices-for.html">
   adapt Google's coding practices</A>
to their research.  It's a good read; check it out!  I did
want to comment on one small comment, because it relates
to a common belief about pair programming:

<BLOCKQUOTE><EM>
 But, of course, effective pair programming requires a lot
 of soft skills and compatible pairs.  I'm not going to
 pretend that this solution works everywhere.
</EM></BLOCKQUOTE>

I don't pretend that pair programming works everywhere, either,
or that everyone should adopt it, but I often wonder about
statements like this one.  Andersen seems to think that pair
programming is a good thing and has helped him and members of
his team's to produce high-quality code in the past.  Why
downplay the practice in a way he doesn't downplay other
practices he recommends?

Throughout, the article encourages the use of new tools and
techniques.  These tools will alter the practice of his students.
Some are complex enough that they will need to be taught, and
practiced over some length of time, before they become an
effective part of the team's workflow.  To me, pair programming
is another tool to be learned and practiced.  It's certainly no
harder than learning git...

Pair programming <EM>is</EM> a big cultural change for many
programmers, and so it does require some coaching and extended
practice.  This isn't much different than the sort of "onboarding"
that Andersen acknowledges will be necessary if he is to adopt
some of Google's practices successfully in his lab upon upon his
return.  Pair programming takes practice and time, too, like most
new skills.

I have seen the benefit of pair programming in an academic setting
myself.  Back when I used to teach our introductory course to
freshmen, I had students pair every week in the closed lab
sessions.  We had thirty students in each section, but only
fifteen computers in our lab.  I paired students in a rotating
fashion, so that over the course of fifteen weeks each student
programmed with fifteen different classmates.  We didn't use a
full-on "pure" XP-style of pairing, but what we did was consistent
with the way XP encourages pair programming.

This was a good first step for students.  They got to know each
other well and learned from one another.  The better students
often helped their partners in the way senior developers can help
junior developers progress.  In almost all cases, students helped
each other find and fix errors.  Even though later courses in the
curriculum did not follow up with more pair programming, I saw
benefits in later courses, in the way students interacted in the
lab and in class.

I taught intro again
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2014-09.html#e2014-09-01T15_17_35.htm">
   a couple of falls ago</A>
after a long time away.  Our lab has twenty-eight machines now,
so I was not forced to use pair programming in my labs.  I got
lazy and let them work solo, with cross-talk.  In the end, I
regretted it.  The students relied on me a lot more to help them
find errors in their code, and they tended to work in the same
insulated cliques throughout the semester.  I don't think the
group progressed as much as programmers, either, even though some
individuals turned out fine.

A first-year intro lab is a very different setting than a research
lab full of doctoral students.  However, if freshmen can learn to
pair program, I think grad students can, too.

Pair programming is more of a social change than a technical
change, and that creates different issues than, say, automated
testing and style checking.  But it's not so different from the
kind of change that capricious adherence to style guidelines
or other kinds of code review impose on our individuality.

Are we computer scientists so maladjusted socially that we can't
-- or can't be bothered -- to learn the new behaviors we need to
program successfully in pairs?  In my experience, no.

Like Andersen, I'm not advocating that anyone require pair
programming in a lab.  But: If you think that the benefits of
pair programming exceed the cost, then I encourage you to
consider having your research students or even your undergrads
use it.  Don't shy away because someone else thinks it can't
work.  Why deprive your students of the benefits?

The bottom line is this.  Pair programming is a skill to be
learned, like many others we teach our students.
-----