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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

EDIT/ADDITION:

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.