<p>I have experienced pair programming as a student.</p>

<p><strong>TL;DR:</strong> 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.</p>

<p><strong>My First Experience (Not very good)</strong></p>

<p>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.</p>

<p>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:</p>

<ul>
<li>As a more experienced programmer myself, I usually ended up doing most of the planning and writing of the program.</li>
<li>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.</li>
</ul>

<p>Heather's answer said something which was also true in my case: </p>

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

<p>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.</p>

<p>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.</p>

<p>Some of the reasons why this experience with pair programming was <strong>a bad one</strong> were:</p>

<ul>
<li>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.</li>
<li>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.)</li>
</ul>

<p><strong>My Second Experience (Better, but not pair programming)</strong></p>

<p>In the second Computer Science class I took, everyone received individual assignments multiple times a week.  We were <strong>not required to program in pairs</strong>.  We had 2-3 hours of lab time twice a week.  The teaching assistant was actually another professor, who was <em>very competent</em> 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.</p>

<p>The reasons that this class was <strong>so much more successful</strong> seemed to be:</p>

<ul>
<li>Good advice was always available.</li>
<li>Anyone could ask anyone else for help.</li>
<li>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.</li>
<li>The students who knew enough to give help could give it to anyone, not just a partner who might not want it.</li>
</ul>

<p>EDIT/ADDITION:</p>

<p><strong>My Third Experience (Pair Programming for Fun)</strong></p>

<p>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.</p>

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

<p>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.</p>

CC BY-SA 4.0
2018-06-24T22:55:14.900Z
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
CC BY-SA 4.0
2018-06-24T22:55:36.177Z
Welcome to [cseducators.se]. 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](https://chat.stackexchange.com/rooms/59174/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
CC BY-SA 4.0
2018-06-25T00:04:12.667Z
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
CC BY-SA 4.0
2018-06-26T00:24:47.270Z
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
CC BY-SA 4.0
2018-06-24T22:27:38.663Z
2018-06-26T01:00:06.163Z
2018-06-26T01:00:06.163Z
jacobandgeckos
<p>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.)</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-03T14:53:18.080Z
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
CC BY-SA 3.0
2017-07-03T14:55:59.377Z
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.
CC BY-SA 3.0
2017-07-03T15:03:23.517Z
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
CC BY-SA 3.0
2017-07-03T15:08:26.067Z
That's a great idea!  I hope I remember it when I teach CS 1 again in the spring.  :)
Chris M.
CC BY-SA 3.0
2017-07-03T15:19:04.337Z
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
CC BY-SA 3.0
2017-07-03T15:22:34.740Z
@ChrisM. Put a card in your Hipster PDA.
Buffy
CC BY-SA 3.0
2017-07-04T13:48:49.587Z
+1 to not forcing students to work together. Some students live off-campus or have quirks or outside responsibilities that make it hard for them to collaborate, although I still encourage them to make an attempt if they think they can manage it. I constantly remind students that programming is a team sport.
Ellen Spertus
CC BY-SA 3.0
2017-07-04T15:18:05.937Z
All of my students live off-campus - we're a community college - so I plan their pair programming so that most of it can be done during class time.
Chris M.
CC BY-SA 3.0
2017-07-03T14:49:50.963Z
2017-07-03T14:49:50.963Z
Chris M.
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>The programmer gets a lot of hands on experience, and also learns an essential tool, which I sometimes call <em>&quot;Evaluation in Runtime&quot;</em>. 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.</p>
<br>
<h3>But,</h3>
<p>It is <em>crucial</em> that the paired students get along. If they have problems working together <em>at the beginning</em>, it might escalate to a very difficult situation indeed.<br />
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.</p>
<p>This means that you'd probably need to see them working, and giving them <em>both</em> 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).</p>
<p>If conflicts between the two arise, you might be able to re-pair <sub>(unintended pun. Well maybe it was intended)</sub> those two, possibly with another problematic pair.</p>
<p>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.</p>
<p>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.</p>

CC BY-SA 3.0
2017-07-03T15:58:06.900Z
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
CC BY-SA 3.0
2017-07-03T16:03:07.820Z
@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
CC BY-SA 3.0
2017-07-03T16:11:20.760Z
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
CC BY-SA 3.0
2017-07-03T15:46:02.353Z
2017-07-03T16:14:57.497Z
2020-06-18T08:36:57.023Z
ItamarG3
<p>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.</p>

<p><strong>It was terrible.</strong> </p>

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-04T12:45:13.817Z
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
CC BY-SA 3.0
2017-07-04T13:29:18.750Z
@nocomprende Hmmm. maybe you, Bennett Brown, and I should start a new school. =)
Buffy
CC BY-SA 3.0
2017-07-03T22:34:10.070Z
2017-07-03T22:34:10.070Z
auden
<p>Many of us use or have used Pair Programming in the classroom. </p>

<p>See <a href="https://www.agilealliance.org/glossary/pairing" rel="nofollow noreferrer">https://www.agilealliance.org/glossary/pairing</a> for a discussion if you like. </p>

<p><a href="http://tandfonline.com/doi/abs/10.1080/08993408.2011.579808" rel="nofollow noreferrer">@BennettBrown has pointed to research showing its advantages</a>, but not all users may have had positive experiences. </p>

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

<p>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. </p>

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

<hr>

<p>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. </p>

<p>If you want to really understand Pair Programming, the book <a href="https://rads.stackoverflow.com/amzn/click/0201745763" rel="nofollow noreferrer">Pair Programming Illuminated</a> is a great place to start. If you want to see Pairing integrated into a complete Agile Programming workflow of a small team, <a href="https://rads.stackoverflow.com/amzn/click/0321278658" rel="nofollow noreferrer">Extreme Programming Explained</a> is good. I actually prefer the first edition if you can find it. </p>

CC BY-SA 3.0
2017-07-03T18:46:23.800Z
Ob Dilbert: http://dilbert.com/strip/2003-01-11
Ellen Spertus
CC BY-SA 3.0
2017-07-03T19:11:39.540Z
@EllenSpertus Hmmm. Would that be one of the advantages or disadvantages? =)
Buffy
CC BY-SA 3.0
2017-07-03T20:40:58.693Z
Your link should point to the review of literature on pair programming (http://www.tandfonline.com/doi/abs/10.1080/08993408.2011.579808) concluding pair programming is best practice. I posted that in https://cseducators.stackexchange.com/questions/1302/how-to-adapt-pair-programming-to-a-shared-terminal-environment-like-cloud9 . Your link in the current question is for a National Academies literature review of active learning I posted in chat.
Bennett Brown
CC BY-SA 3.0
2017-07-03T20:43:23.343Z
That came from an edit by another. I'll update it. Thanks. I hope you want to put in an answer here somewhere.
Buffy
<best-practice><classroom-management><pair-programming>
What advantages/disadvantages have you seen with Pair Programming in the classroom
# What advantages/disadvantages have you seen with Pair Programming in the classroom

(Asked by: username_0 on 2017-07-03)

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](http://tandfonline.com/doi/abs/10.1080/08993408.2011.579808), 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](https://rads.stackoverflow.com/amzn/click/0201745763) 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](https://rads.stackoverflow.com/amzn/click/0321278658) is good. I actually prefer the first edition if you can find it.

**Tags:** best-practice, classroom-management, pair-programming

> **Comments:**
> **username_1**: Ob Dilbert: http://dilbert.com/strip/2003-01-11  
> **username_0**: @EllenSpertus Hmmm. Would that be one of the advantages or disadvantages? =)  
> **username_2**: Your link should point to the review of literature on pair programming (http://www.tandfonline.com/doi/abs/10.1080/08993408.2011.579808) concluding pair programming is best practice. I posted that in https://cseducators.stackexchange.com/questions/1302/how-to-adapt-pair-programming-to-a-shared-terminal-environment-like-cloud9 . Your link in the current question is for a National Academies literature review of active learning I posted in chat.  
> **username_0**: That came from an edit by another. I'll update it. Thanks. I hope you want to put in an answer here somewhere.  

---

## 4 answers

### Answer by username_5 on 2017-07-03. Score: 4

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.

> **Comments:**
> **username_0**: 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.  
> **username_5**: 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.  
> **username_0**: 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.  
> **username_5**: That's a great idea!  I hope I remember it when I teach CS 1 again in the spring.  :)  
> **username_6**: 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.  
> **username_0**: @ChrisM. Put a card in your Hipster PDA.  
> **username_1**: +1 to not forcing students to work together. Some students live off-campus or have quirks or outside responsibilities that make it hard for them to collaborate, although I still encourage them to make an attempt if they think they can manage it. I constantly remind students that programming is a team sport.  
> **username_5**: All of my students live off-campus - we're a community college - so I plan their pair programming so that most of it can be done during class time.  

---

### Answer by username_7 on 2017-07-03. Score: 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.

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.

> **Comments:**
> **username_0**: 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.  
> **username_7**: @username_0 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.  
> **username_0**: 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.  

---

### Answer by username_8 on 2017-07-03. Score: 2

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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: @nocomprende Hmmm. maybe you, username_2, and I should start a new school. =)  

---

### Answer by username_3 on 2018-06-24. Score: 1

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.

> **Comments:**
> **username_0**: 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.  
> **username_4**: Welcome to [cseducators.se]. 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](https://chat.stackexchange.com/rooms/59174/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.  
> **username_0**: 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.  
> **username_3**: 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."  

---

