# What advantages/disadvantages have you seen with Pair Programming in the classroom

Many of us use or have used Pair Programming in the classroom.

See https://www.agilealliance.org/glossary/pairing for a discussion if you like.

@BennettBrown has pointed to research showing its advantages, but not all users may have had positive experiences.

If you have tried it, what have you experienced both on the positive side and the negative side.

Perhaps more important is what else do you need to do in structuring your course to make up for any disadvantages or support any advantages. These might involve ensuring fairness in sharing work or in grading.

I tend to use it at every level, but there may be issues you see in various courses.

The answers seem to indicate a fair amount of misunderstanding of Pair Programming. It is not just two people assigned to a task. That can lead to division of labor, which often fails. If two people just divide up the work and do it unwisely, they have the additional task of integrating their work which can be very difficult. Neither is it one person just working and the other just "reviewing". It is a much more cooperative endeavor.

If you want to really understand Pair Programming, the book Pair Programming Illuminated is a great place to start. If you want to see Pairing integrated into a complete Agile Programming workflow of a small team, Extreme Programming Explained is good. I actually prefer the first edition if you can find it.

• Ob Dilbert: dilbert.com/strip/2003-01-11 – Ellen Spertus Jul 3 '17 at 18:46
• @EllenSpertus Hmmm. Would that be one of the advantages or disadvantages? =) – Buffy Jul 3 '17 at 19:11
• Your link should point to the review of literature on pair programming (tandfonline.com/doi/abs/10.1080/08993408.2011.579808) concluding pair programming is best practice. I posted that in cseducators.stackexchange.com/questions/1302/… . Your link in the current question is for a National Academies literature review of active learning I posted in chat. – Bennett Brown Jul 3 '17 at 20:40
• That came from an edit by another. I'll update it. Thanks. I hope you want to put in an answer here somewhere. – Buffy Jul 3 '17 at 20:43

I give 11 lab assignments in CS 1, and I assign partners for the first four or five so that students get to know each other, and then I let them choose their partners, or choose to work alone. I try to discourage them from working alone, but some students just don't want to deal with people, and I feel bad forcing them. (I also give six projects, worth more collectively than the 11 labs are, and they must work on these separately.)

This is all anecdotal, because I only teach one section of CS 1 a semester, but: I don't see any patterns. Some more socially awkward students find the right partner and have lots of success building skills and confidence during the semester, whereas others don't, and struggle alone for the rest of the semester. Frequently, students who come in with previous knowledge (say, those taking the class the second time) will ignore their partners, or do the work and hand them the answer; but others seem to have the "teaching gene" and almost act like TAs for me with the weaker students. It depends a lot on who the students are, and how lucky I get when I pair them up.

I do give each student a questionnaire the first day, so that I can try to match up the students with similar experience, or students that have already passed Calc I, or something, but (again, based on anecdotal data with a very small $n$) none of these seems to have much of an effect.

I'll be watching this discussion to see if anyone has done a lot of research on who to match up with whom, because I haven't figured it out yet.

• I might do a questionnaire at the end of the course, asking: Who was your "best" partner this term, and why". I do similar things with other teamwork, being careful to ask for positive things only. – Buffy Jul 3 '17 at 14:53
• That's an interesting idea. I would really like this information from students who don't stick around until the end of the semester, too. if I could figure out a way to get it. – Chris M. Jul 3 '17 at 14:55
• You could ask on one or several assignment: What was your partner's best contribution and what was your own. You learn a lot from this sort of question. I once had a student that I thought was slacking, but his teammates rated him very highly. His grade got a big bounce. – Buffy Jul 3 '17 at 15:03
• That's a great idea! I hope I remember it when I teach CS 1 again in the spring. :) – Chris M. Jul 3 '17 at 15:08
• One question that might be worth asking in your initial survey is what times the student thinks they'll be generally available to work on their homework (since students have different obligations and may be unavailable at a particular day/time). Pair programming goes much more smoothly if the pair can actually meet in person, so it might help to explicitly try and facilitate that. – Michael0x2a Jul 3 '17 at 15:19

I have seen pair programming both succeed spectacularly and fail miserably. The difference comes from a combination of a few factors, which are, in a way, the advantages and disadvantages of Pair Programming.

One clear advantage is that both students in the pair get experience in writing code, and later reviewing code. (The pair programming I saw had students switching places every so often). This is a great way to give students the skills of coding and reviewing.

Reviewing a peer's code can give the reviewing student 1) a broader perspective of code writing and 2) a toolbox for self-evaluation. So pair programming is very good for the reviewer.

The programmer gets a lot of hands on experience, and also learns an essential tool, which I sometimes call "Evaluation in Runtime". This means that the programmer learns how to evaluate their work as they go, because they are given feedback from the reviewer. So the coder gets a lot of experience and some very important skills, which is great.

### But,

It is crucial that the paired students get along. If they have problems working together at the beginning, it might escalate to a very difficult situation indeed.
All those amazing things I described earlier would all crumble to bits. So you have to be on the lookout for potential fights early on.

This means that you'd probably need to see them working, and giving them both tips on how to work together (such as telling the programmer that the reviewer sees things differently, and that they should listen to one another).

If conflicts between the two arise, you might be able to re-pair (unintended pun. Well maybe it was intended) those two, possibly with another problematic pair.

It's also a good skill to learn how to work with people you'd rather not work with. But this situation is, as I see it, a last resort.

And for ensuring fairness in sharing work, instruct the students to switch places every half hour or so. Depending on how much time you have, it's ideal that each students has as much experience in both position.

• It sounds like your students don't sit at one screen with one "driving" and the other "navigating" (the classic version), but something different. Can you spell out the scenario a bit? Thanks in advance. – Buffy Jul 3 '17 at 15:58
• @Buffy what students do is like this: One writes code, the other sits next to the first one, and reviews it as it's being written. With that in mind, I hope my answer makes more sense. – ItamarG3 Jul 3 '17 at 16:03
• Closer to the standard, then. But if I'm "navigating" I constantly make comments, about variable names, maybe, or structure, or needed tests. Sometimes just to remind the "driver" of past decisions. The advantage of two is, partly, that the driver takes a microscopic view of the problem, but the navigator, with less responsibility takes a wider, overall view. This has been observed to emerge in practice and doesn't need to be taught. But there should be a continuing conversation, so that the navigator doesn't take the narrow view also. If the driver gets stuck they should switch roles. – Buffy Jul 3 '17 at 16:11

I've been in groups before, and multiple people were supposed to code. It was a system where you had to be on the same computer for it to work. It fairly well approximated pair programming - we were discussing out loud, and one person was watching the other giving suggestions, and the other was coding. The people in the group that I was mostly working with weren't annoying, and a couple were semi-friends.

It was terrible.

I'd programmed before the class and the other student hadn't, so I was a bit better. That made it even harder, because the other student was less likely to, say, use a function, or make some aspect simpler, or whatever - so I felt like I was taking over too much to fix something, or suggest a better solution, and I ended up doing more of the coding.

There was a time limit, obviously, so since I was faster at coding (and I also could keyboard, whereas the other student couldn't), the other student often was like, "hey, we need to get this done, you obviously know how to do it - just do it". The teacher stepped in and put the other student at the keyboard, but since a. the other student couldn't keyboard, (just pecked) and b. both of us now felt even more rushed, because the rest of the group had finished some of the mechanical aspects (we were in an engineering course creating a "elevator" type thing), the whole thing just got worse.

• Let me suggest (a) that the purpose of the exercise was to produce learning, not a program, and (b) I hope that the instructor was wise enough to see the picture you describe and act appropriately. Perhaps you both missed point (a). When I PP with a novice I realize that I have a different job then when doing it with a pro. But, even in a workplace situation, bringing the novice up to speed benefits everyone in the long run - but it is problematic if the manager (or teacher) doesn't agree. – Buffy Jul 4 '17 at 12:45
• @nocomprende Hmmm. maybe you, Bennett Brown, and I should start a new school. =) – Buffy Jul 4 '17 at 13:29

You asked for my experience, so:
30 years ago in my last year of a BS CS (Engr) program, we had a 3 term course where we wrote a compiler for a simplified language, including producing 68020 assembly language. This course required us to work in pairs for most of the coding. There was an odd number of students so there was one triple of women as well.

Most of the students had encountered each other before, so they paired up with someone they knew. But I had transferred from another college a year back, so I looked across the room at the only available person and we introduced ourselves. Over time she became a close friend, then a girlfriend. We were so close in fact that we would argue heatedly in the terminal rooms, which shocked some of our classmates.

We shared the design and coding pretty equally, but often worked apart. I never got used to her tendency to set the foreground color vivid blue and the background vivid red. Our compiler actually worked at the end - which was unusual - and I think it passed all the requirements.

I never did any pair programming again, because for the most part, I was working on solo projects at the company I worked for. I was also one of only 3 programmers who knew C and so did not have to use Cobol, like the 30 other programmers (most of whom were women). I do work very closely now with my co-instructor where I teach.

Since I do not use it as a teaching technique in our (very small) classes, I can't report on advantages and disadvantages. I have never felt that it would help our students to work in that way. From my experience as a student, it is great if your partner is also... your partner, so to speak, but that was probably not intended by the curriculum.

• Interesting. My experience is quite different. I find that I don't work especially effectively with someone I'm emotionally attached to in some situations (teaching/learning situations). I don't know whether that is just my problem or is common. I can program with close friends, though, especially if we have a sort of mind-meld on goals and strategies. That was more your situation, I think. But the industry experience doesn't say that the mind-meld is essential to PP. – Buffy Jul 4 '17 at 12:51

I have experienced pair programming as a student.

TL;DR: From my experience, I do not recommend pair programming, but I do recommend a course structure where students can ask each other for assistance. This way, students who need and want assistance can get it, and students who are able to give assistance can give it. The ability of the professor or TA in the lab can make a big difference.

My First Experience (Not very good)

EDIT: It seems that this was intended to be pair programming, but due to it being badly explained to the students, it ended up just being "division of labor." In reality in my experience, the review component of pair programming was not really present. I mistook the goal of pair programming - I don't think pair programming is intended to be able to give the students I worked with the amount of help that they needed. If you use Pair Programming as a teaching technique, you should make sure it is explained better than it was explained to me, and make sure students are actually following the procedure. END EDIT.

In the first Computer Science class I took, there was a 2-3 hour lab once a week, and (we) the students were randomly assigned new partners with whom to work on labs every week. There were two student teaching assistants, one who seemed perfectly competent, and one who everyone dreaded (nobody could understand what he was saying at all, but he would talk on and on and demand your attention). There would be an assigned program to write, and a lab report. The balance of work was generally this:

• As a more experienced programmer myself, I usually ended up doing most of the planning and writing of the program.
• My partner would usually write the "lab report". They often did not understand programming very well, but felt that they could contribute by writing a lab report.

Heather's answer said something which was also true in my case:

The other student often was like, "hey, we need to get this done, you obviously know how to do it - just do it".

Many times, I tried my best to get them to understand the code I was writing, pointing out lines of code, explaining functions, describing concepts... but as far as I could tell, most of my efforts were lost. Whenever I actually tried to get my partner to write some of the code, our efforts would start to go nowhere very fast.

One time, when we were learning a topic considered difficult for the class, the professor came in to help with the lab, and he really made sure everyone got the help they needed to understand the concept. That was the only time it seemed that the lab was really successful in terms of most students learning.

Some of the reasons why this experience with pair programming was a bad one were:

• My partners did not seem invested in learning about programming (they were fine with only doing what they needed to in order to pass the class). Other students in the class might have been invested in learning, but not any of my partners.
• Good advice was often unavailable. (The students tended to rely only on their partners or an available TA for assistance. The one competent TA was often busy, and sometimes neither partner knows what to do.)

My Second Experience (Better, but not pair programming)

In the second Computer Science class I took, everyone received individual assignments multiple times a week. We were not required to program in pairs. We had 2-3 hours of lab time twice a week. The teaching assistant was actually another professor, who was very competent whenever people asked him for assistance. Although people were not assigned pairs, students who needed help would often ask other students who they knew were competent programmers for help.

The reasons that this class was so much more successful seemed to be:

• Good advice was always available.
• Anyone could ask anyone else for help.
• The people who wanted and needed help were always able to get it, not stuck with a partner who might know as little as they know.
• The students who knew enough to give help could give it to anyone, not just a partner who might not want it.

My Third Experience (Pair Programming for Fun)

My friend and I meet every couple of weeks and code together for fun. This is completely separate from any form of classroom, academic work, or job. What we usually do seems to fit the definition/intention of Pair Programming far better than any classroom Pair Programming experience I have had. One of us typically codes while the other watches/gives comments, switching off depending on who better understands the particular task. This is enjoyable and we both learn a great deal.

However, in this situation, we are both already fairly competent at programming, and motivated to program and learn.

It is unfortunate, but I cannot really see this succeeding in most academic environments I have been in, because of a lack of motivation in so many students. I would love to be in a classroom where everyone is motivated enough and has sufficient programming skills for Pair Programming to be successful, but I don't think that I have yet been in any classroom like it.

• Actually, your first experience was not pair programming. It was just two people assigned to one task. That isn't at all what pair programming is like. Division of labor is not one of the goals of pair programming and just as you say, it often fails. It often fails in just the way you suggest. But it isn't an example of Pair Programming. – Buffy Jun 24 '18 at 22:55
• Welcome to Computer Science Educators. Input like this is quite useful to instructors trying to develop courses and classes that will help the students learn the material, not just get a grade. I certainly hope we see more of your input and experience on the site. Once you have 20, or more, reputation points you can also join the conversation in The Classroom which is a chatroom dedicated to this site. It's often quiet, but it can get lively when new questions show up, or things get lively on the site. – Gypsy Spellweaver Jun 24 '18 at 22:55
• To add to my earlier comment: A common problem is technology generally and programming in particular is what happens when some successful methodology is widely adopted but adopted partially or badly without understanding. You hear things like "X just doesn't work", when in fact X wasn't really tried. There are many synergistic aspects of some things and when parts are omitted, the synergy isn't there anymore. Your post is, therefore really valuable, though not as a criticism of Pair Programming. Division of Labor often fails to take into account that the work of two must be then integrated. – Buffy Jun 25 '18 at 0:04
• Interesting... I believe my first experience was intended to be pair programming, but I ended up being the driver, and my partners were not skilled enough to be the driver, or even the observer in most cases. I ended up doing both the driving and the observing (in hopes my partner would learn a thing or two). It was not well explained, but it was the intention for us to be Pair Programming. In light of the bad explanation, most students (myself included) took "Pair Programming" to mostly mean, "We only have to do half the work." – jacobandgeckos Jun 26 '18 at 0:24