Answers.Body: <p>Having them do it for homework, and pair program is a big ask. However here is some of my experience with pair programming.</p>
  
  <p>While working as part of a software team, we tried to introduce pair programming, but got lots of resistance, even from the evangelists (no one had done it before, but it seemed like a good idea).</p>
  
  <h2>What worked</h2>
  
  <ul>
  <li><p>Pairing with someone that had done it before: At one point we had a contractor that had done pair programming before, when I worked with him, I did pair programming. This experience showed me that it could work. The only people, that are available and have done it before are the year above. A good way to lean is to teach. Therefore pair students with someone from the year above. This way the student in the lower year learns to pair program, and the one in the upper year learns by helping. [You need some intensive to stop the upper year student doing too much work. There is also a bootstrap problem.]</p></li>
  <li><p>We had read that it takes sometime before pair programming pays off (2 weeks of full time programming, if I remember correctly). We kept giving up on pair programming during this investment phase. However we did discover that if the task is sufficiently hard, then the pay off was immediate. These were problems where we both had enough language experience, the problem was well defined, but nether of us knew how to solve the problem. e.g. setting up the MMU on an ARM processor. One of us knew what they wanted it to do. The other knew what an MMU does, but nether had ever set one up before. Therefore once they have learnt to program, give them a task that would be very difficult to do on there own, and get them to pair it.</p></li>
  <li><p>Non programming activities: for various design tasks (algorithms and higher level than code), we worked in pairs or small teams (2,3 sometimes as many as 5). This worked well for tasks that are hard. Therefore start pairing with non-programming tasks.  </p></li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-17T10:55:25.017Z
Answers.LastActivityDate: 2017-08-17T10:55:25.017Z
Answers.UserDisplayName: ctrl-alt-delor
Answers.Body: <p>I find it difficult to predict success with the setup you describe. There are too many forces working against you. If your students are all residential and/or do most of their programming in labs that you provide then success might be possible, but otherwise, not likely. </p>
  
  <ul>
  <li>Students resist pairing and don't really know how to do it effectively. They don't understand what benefits it has until they see it work for themselves. They are unlikely to actually do it outside your view. </li>
  <li>Students find it difficult to find the time in their schedule to actually work together at one screen. Remote pairing tools are available, but not great, and probably work only for those already committed and experienced. </li>
  </ul>
  
  <p>Making the project harder isn't really going to help you and it will frustrate at least some of your students. Letting them choose their own partners will encourage nothing new as they likely do some of that already but without real pairing. Also, letting them choose pairs doesn't get the real benefit of switching pairs and thereby spreading knowledge. Things happen outside your view, as you say. They will do as they wish and tell you what they think you want to hear. </p>
  
  <p>Lecturing about pairing is especially ineffective. You have to show it and you have to let them experience it. Letting them opt-out gives you and them nothing at all. The people who want to work alone probably need the experience of working with someone else at least as much as the others. </p>
  
  <p>Collecting feedback is, to me, the best part of your plan. But you should do that for all projects anyway. </p>
  
  <hr>
  
  <p>I would do something like the following, though it will disrupt your class for a week. </p>
  
  <ol>
  <li><p>Decide how many teams you should have so that there are 4-6 members per team. You choose the team captains. If the students don't know one another, then assign teams randomly. I used a deck of (handmade) cards with team names. People pick a card. That is their team. If they do know one another then "sandlot baseball" team choosing works well. In rotation, each captain picks their next team member from the remaining students in the class. This assures that there is a mix of abilities on each team and that teammates are "sort of" friendly without overemphasizing tribes and clans. Team "captains" have no management role. You can ask them to provide you feedback on how the team is doing and what it needs for success, but their job is not to tell people what to do. </p></li>
  <li><p>Decide that you will spend a week of class time on pairing and kickstarting the project. Use a flipped classroom style for that week so that students read at home but work during class time. Other than reading there are no assignments during that week. You can spend a short amount of time at the <em>end</em> of each class period asking about questions on the reading. Don't start with this, though, or you won't know when to stop. </p></li>
  <li><p>The first hour (or so) of the week in question is a demonstration, in which you and one of your students (maybe a captain), pair on the project itself. I would also incorporate test-first programming into this demonstration. Write no code until you have a failing test. Switch roles with your "partner". Switch partners also. Distribute any code you build to the class at the end so that they have a starting point. No code is written by any individual. Ever. For any reason. Just Say No. </p></li>
  <li><p>If you really want the students to do this, there is one more aspect of agile development that you should adopt. Rather than having the students work from an overall narrative that informally specifies the project, or a formal specification that does so explicitly, give them the project as a "project backlog" (Scrum terminology). This is a list of cards that you have written that lay out the features of the project, one feature per card. The features are incompletely specified so you will need, as the project proceeds, to answer questions about what you really want. Each week you select a subset of the backlog for development that week. </p></li>
  <li><p>The student teams work in the classroom, not at home for that entire week. Work hard on giving them feedback both on their product, but also on their process, as the week goes on. After one week you can probably turn them loose, but it would be good if you can supply them with a place in which they can continue to work as if they were in class, with the whole team (4-6) people there simultaneously. A cafeteria might work, but not a library unless it has work rooms used for small group discussion. </p></li>
  <li><p>It is very useful if you can provide the class with an always-on communication channel in which they can always ask for and get help. This needs to be more than just email to/from you. A chatroom or a wiki works. So does an email distribution list to which everyone in the class can contribute. This makes the course 24 by 7, of course and you need to be available to give feedback. But the students should themselves feel empowered to answer questions that appear on the list. I didn't try to keep the teams from communicating with each other, even though the teams were working on the same project. Teams "copying" from one another was never an issue since information was basically free. </p></li>
  </ol>
  
  <p>Note that I've used this successfully. Pairing, test-first, product backlogs, and small teams is a synergistic whole. But they need <em>supervised</em> practice or they won't see its benefit nor give it a fair trial. They also need a place and time to work together that won't disrupt their otherwise busy schedules. </p>
  
  <p>Finally, make process feedback an important part of the project. You can ask for this to be given live or in writing. I found it useful to provide an anonymous feedback channel so that I could learn things that students wouldn't otherwise say. </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-17T12:05:38.773Z
Answers.LastActivityDate: 2017-08-17T12:05:38.773Z
Answers.UserDisplayName: Buffy
Body: <p>Suppose I've assigned a project and asked students to pair into two-person teams. I'd like each team to pair-program: work together in person to complete the assignment.</p>
  
  <p>Some students will do this, but sometimes they don't: either one partner monopolizes the work (which hurts the other partner) or the two partners split up the work and work independently (so both students end up having gaps in their knowledge).</p>
  
  <p>I'd like to avoid this as much as possible, which brings me to my core question: <strong>what can I do to encourage as many students as possible to (effectively) pair program?</strong></p>
  
  <p>I read <a href="https://cseducators.stackexchange.com/q/1383/732">this post</a>, which included a several nuggets of useful advice, but am interested in collecting more, if possible.</p>
  
  <p>So far, I plan to:</p>
  
  <ol>
  <li>Allocate time to promote pair programming in lecture</li>
  <li>Let students chose their own groups + provide an (optional) survey to help pair students</li>
  <li>Let students petition to work individually if they really want to</li>
  <li>Skew the projects towards the difficult side to try and get them to at least talk to each other (and provide plenty of office hours as a safety net)</li>
  <li>Collect partner feedback at the end and factor that into their final grades</li>
  </ol>
  
  <p>I have no idea how effective these policies will be, though. I'd welcome both suggestions for encouraging pair programming in general as well as feedback on these specific ideas.</p>
  
  <p>Note that this is for a university-level class, and that due to time constraints, all homework needs to be done outside of the classroom (so I can't watch them pair program and offer suggestions or really enforce anything).</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-17T09:45:51.057Z
Comments.Text: Are you a residential college/university? Do most of your students live on campus or very locally?
Comments.UserDisplayName: Buffy
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-08-18T01:16:12.603Z
Comments.Text: @Buffy -- I'd estimate the majority of the students live on or near campus, but a decent subset of the students are commuters. As I'm sure you're going to say, that's yet another problem...
Comments.UserDisplayName: Michael0x2a
Tags: <undergraduate><project><pair-programming>
Title: Techniques for encouraging pair programming
ThreadText: # Techniques for encouraging pair programming
  
  (Asked by: username_0 on 2017-08-17)
  
  Suppose I've assigned a project and asked students to pair into two-person teams. I'd like each team to pair-program: work together in person to complete the assignment.
  
  Some students will do this, but sometimes they don't: either one partner monopolizes the work (which hurts the other partner) or the two partners split up the work and work independently (so both students end up having gaps in their knowledge).
  
  I'd like to avoid this as much as possible, which brings me to my core question: **what can I do to encourage as many students as possible to (effectively) pair program?**
  
  I read [this post](https://cseducators.stackexchange.com/q/1383/732), which included a several nuggets of useful advice, but am interested in collecting more, if possible.
  
  So far, I plan to:
  
  1. Allocate time to promote pair programming in lecture
  2. Let students chose their own groups + provide an (optional) survey to help pair students
  3. Let students petition to work individually if they really want to
  4. Skew the projects towards the difficult side to try and get them to at least talk to each other (and provide plenty of office hours as a safety net)
  5. Collect partner feedback at the end and factor that into their final grades
  
  I have no idea how effective these policies will be, though. I'd welcome both suggestions for encouraging pair programming in general as well as feedback on these specific ideas.
  
  Note that this is for a university-level class, and that due to time constraints, all homework needs to be done outside of the classroom (so I can't watch them pair program and offer suggestions or really enforce anything).
  
  **Tags:** undergraduate, project, pair-programming
  
  > **Comments:**
  > **username_1**: Are you a residential college/university? Do most of your students live on campus or very locally?  
  > **username_0**: @username_1 -- I'd estimate the majority of the students live on or near campus, but a decent subset of the students are commuters. As I'm sure you're going to say, that's yet another problem...  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-08-17. Score: 2
  
  Having them do it for homework, and pair program is a big ask. However here is some of my experience with pair programming.
  
  While working as part of a software team, we tried to introduce pair programming, but got lots of resistance, even from the evangelists (no one had done it before, but it seemed like a good idea).
  
  ## What worked
  
  * Pairing with someone that had done it before: At one point we had a contractor that had done pair programming before, when I worked with him, I did pair programming. This experience showed me that it could work. The only people, that are available and have done it before are the year above. A good way to lean is to teach. Therefore pair students with someone from the year above. This way the student in the lower year learns to pair program, and the one in the upper year learns by helping. [You need some intensive to stop the upper year student doing too much work. There is also a bootstrap problem.]
  * We had read that it takes sometime before pair programming pays off (2 weeks of full time programming, if I remember correctly). We kept giving up on pair programming during this investment phase. However we did discover that if the task is sufficiently hard, then the pay off was immediate. These were problems where we both had enough language experience, the problem was well defined, but nether of us knew how to solve the problem. e.g. setting up the MMU on an ARM processor. One of us knew what they wanted it to do. The other knew what an MMU does, but nether had ever set one up before. Therefore once they have learnt to program, give them a task that would be very difficult to do on there own, and get them to pair it.
  * Non programming activities: for various design tasks (algorithms and higher level than code), we worked in pairs or small teams (2,3 sometimes as many as 5). This worked well for tasks that are hard. Therefore start pairing with non-programming tasks.
  
  
  ---
  
  ### Answer by username_1 on 2017-08-17. Score: 2
  
  I find it difficult to predict success with the setup you describe. There are too many forces working against you. If your students are all residential and/or do most of their programming in labs that you provide then success might be possible, but otherwise, not likely.
  
  * Students resist pairing and don't really know how to do it effectively. They don't understand what benefits it has until they see it work for themselves. They are unlikely to actually do it outside your view.
  * Students find it difficult to find the time in their schedule to actually work together at one screen. Remote pairing tools are available, but not great, and probably work only for those already committed and experienced.
  
  Making the project harder isn't really going to help you and it will frustrate at least some of your students. Letting them choose their own partners will encourage nothing new as they likely do some of that already but without real pairing. Also, letting them choose pairs doesn't get the real benefit of switching pairs and thereby spreading knowledge. Things happen outside your view, as you say. They will do as they wish and tell you what they think you want to hear.
  
  Lecturing about pairing is especially ineffective. You have to show it and you have to let them experience it. Letting them opt-out gives you and them nothing at all. The people who want to work alone probably need the experience of working with someone else at least as much as the others.
  
  Collecting feedback is, to me, the best part of your plan. But you should do that for all projects anyway.
  
  ---
  
  I would do something like the following, though it will disrupt your class for a week.
  
  1. Decide how many teams you should have so that there are 4-6 members per team. You choose the team captains. If the students don't know one another, then assign teams randomly. I used a deck of (handmade) cards with team names. People pick a card. That is their team. If they do know one another then "sandlot baseball" team choosing works well. In rotation, each captain picks their next team member from the remaining students in the class. This assures that there is a mix of abilities on each team and that teammates are "sort of" friendly without overemphasizing tribes and clans. Team "captains" have no management role. You can ask them to provide you feedback on how the team is doing and what it needs for success, but their job is not to tell people what to do.
  2. Decide that you will spend a week of class time on pairing and kickstarting the project. Use a flipped classroom style for that week so that students read at home but work during class time. Other than reading there are no assignments during that week. You can spend a short amount of time at the *end* of each class period asking about questions on the reading. Don't start with this, though, or you won't know when to stop.
  3. The first hour (or so) of the week in question is a demonstration, in which you and one of your students (maybe a captain), pair on the project itself. I would also incorporate test-first programming into this demonstration. Write no code until you have a failing test. Switch roles with your "partner". Switch partners also. Distribute any code you build to the class at the end so that they have a starting point. No code is written by any individual. Ever. For any reason. Just Say No.
  4. If you really want the students to do this, there is one more aspect of agile development that you should adopt. Rather than having the students work from an overall narrative that informally specifies the project, or a formal specification that does so explicitly, give them the project as a "project backlog" (Scrum terminology). This is a list of cards that you have written that lay out the features of the project, one feature per card. The features are incompletely specified so you will need, as the project proceeds, to answer questions about what you really want. Each week you select a subset of the backlog for development that week.
  5. The student teams work in the classroom, not at home for that entire week. Work hard on giving them feedback both on their product, but also on their process, as the week goes on. After one week you can probably turn them loose, but it would be good if you can supply them with a place in which they can continue to work as if they were in class, with the whole team (4-6) people there simultaneously. A cafeteria might work, but not a library unless it has work rooms used for small group discussion.
  6. It is very useful if you can provide the class with an always-on communication channel in which they can always ask for and get help. This needs to be more than just email to/from you. A chatroom or a wiki works. So does an email distribution list to which everyone in the class can contribute. This makes the course 24 by 7, of course and you need to be available to give feedback. But the students should themselves feel empowered to answer questions that appear on the list. I didn't try to keep the teams from communicating with each other, even though the teams were working on the same project. Teams "copying" from one another was never an issue since information was basically free.
  
  Note that I've used this successfully. Pairing, test-first, product backlogs, and small teams is a synergistic whole. But they need *supervised* practice or they won't see its benefit nor give it a fair trial. They also need a place and time to work together that won't disrupt their otherwise busy schedules.
  
  Finally, make process feedback an important part of the project. You can ask for this to be given live or in writing. I found it useful to provide an anonymous feedback channel so that I could learn things that students wouldn't otherwise say.
  
  
  ---
  
  