<p>An extension I've come to appreciate is one where you have a "driver", "observer/navigator" and "keeper". </p>

<p>This last role might be considerably more difficult, depending on the lab. The idea is to have someone who keeps track of the <em>design</em>. This means that at the start of the lab, the students should all (or just those who start as keepers) dedicate a bit of time to read up online about design patterns in the language they are using. It's important "not to delve too deep". Just a general idea of what "design patterns" means.</p>

<p>Then they begin working. Two out of the three work in usual pair-programming workflow. The third <strong>keeps</strong> in mind the design of the program. As with regular pair-programming, the students should switch roles every now and then. In the case of a trio, they should obviously cycle.</p>

<p>If not all students in the lab are in trios, then an additional for the navigator is to remember design patterns. It should be made clear that it's not their primary task, but that it would definitely help with debugging and maintaining the code.</p>

<p>The added bonus of this extension of pair programming is that students are exposed to design patterns. Seeing as they can sometimes be a complicated matter, starting to tackle them is better done sooner than later.</p>

<p>I have found this solution quite useful in labs about subjects in OOP (the more complex the system, the more important SOLID principles become).</p>

CC BY-SA 3.0
2017-12-13T10:59:00.150Z
2017-12-13T10:59:00.150Z
ItamarG3
<p>tl;dr: This isn't an either/or sort of situation. You have a lot of options for structuring the exercise.</p>
<p>There are a lot of possibilities and which works best depends on the specifics of your situation. Don't lose track of the fact that your goal is educational, however, and not code production. If the students learn but not much code gets produced it can still be a success depending on other parameters. Since I'm going to try to cover a lot of options it will be something of an IFTTT answer.</p>
<p>For all of the cases below it might be best if you don't have one triple or one solo and the rest pairs. It will probably work better for your own learning about this situation if you have, say, <em>three</em> triples and the rest paired or three singles. You then get a better picture of how pairing itself differs from other options.</p>
<h2>If you are willing to have some programmers work alone</h2>
<p>A few days prior to the exercise let each student make a written bid on whether they want to pair or not. Have them give reasons for their preference. Let them know that their preference may not be able to be honored. Look at the bids and decide based on their reasons and your judgement about what would serve everyone best.</p>
<h2>If you have a single superstar who always makes perfect marks</h2>
<p>It is possible that he/she doesn't actually need the practice of this lab so give that person a different task, perhaps as a resource to the remaining pairs, answering questions, prompting, helping you watch over the flock. Someone needs to answer questions as they arise anyway and it might be an opportunity for a person to learn at a more meta level. If your superstar has expressed an interest in teaching eventually this might have additional payoffs for the person. Likewise if he/she is a language lawyer it might help them dig deep into their knowledge on the fly.</p>
<h2>If you have a single struggler (or 3)</h2>
<p>You could put him/her into a triple with others not terribly far advanced from that person's state. In this case, be prepared to be a fourth member of that team to help them keep the situation moving and the process easy and friendly. Don't let the struggler avoid the programmer role. Your choice of teams here might have to depend on personal qualities. Don't put him/her with the arrogant monster.</p>
<h2>If the lab is long (say 3+ hours) or if each pair contributes differently to a larger goal</h2>
<p>This one is a bit riskier with youngsters but works fine with professionals. Choose teams in any way that suits you (see above) and let the process run for a while (half hour to one hour). It needs to be long enough that switching roles has happened a few times. Then change the teams. Note that some people will move to a team with new code they haven't yet seen (the risk factor). At the switch point, the current driver stays with the code and the navigator(s) find new seats. The current driver for that code just continues after the break and the new navigators(s) spend some time catching up. If a person has been solo or in a triple in one iteration they are in a pair for the next. In many ways this is the most realistic scenario and matches how pairing is done in organizations. The advantage of this in the classroom is that students learn to read and understand new code - a useful skill on its own. However, you may need to map out in advance who the pairs/triples will be for each segment. Each student caries a card with them listing who they worked with and if you want to do peer evaluation, each can mark at the end who they thought was their most effective partner. If they work with at least five others, I would ask them to mark their two most effective partners. Don't ask for criticism of partners, just for who contributed the most. Make sure they know in advance that this will happen - to encourage good behavior. A more elaborate peer evaluation is to also ask why they marked the people they did - who was most effective and why.</p>
<h2>In any case</h2>
<p>Don't neglect to set aside time at the end or in the next session to have a retrospective on both the project itself and the process. You could also ask for a written assessment from each student on what worked and what didn't.</p>
<h2>And don't neglect...</h2>
<p>Don't lose track of the purpose and benefit of pairing. The driver takes a tactical, microscopic view of the code being produced and the navigator takes a strategic, macroscopic view. Work to keep this concept going as well as possible. It is the essence.</p>
<h2>Additional advice</h2>
<p>If you poll the student preferences as suggested above (even in conjunction with a different option) it would be good to announce your decisions a day or so in advance when you can't meet all desires. This gives you a chance to explain (privately) to some why their choice couldn't be honored. &quot;I really need you to ...&quot;</p>
<p>And be clear in your own mind, and let the students know, what is the main goal of this exercise. Is the project itself more important or is learning something about the process. When you have to make compromises do so with that goal in mind.</p>

CC BY-SA 3.0
2017-12-13T12:37:14.330Z
I intend to continue to think about this and may update it.
Buffy
CC BY-SA 3.0
2017-12-13T13:04:50.483Z
What is *IFTTT*?
Ben I.
CC BY-SA 3.0
2017-12-13T13:15:46.073Z
IF This Then That: https://en.wikipedia.org/wiki/IFTTT
Buffy
CC BY-SA 3.0
2017-12-20T03:44:09.483Z
The"perfect student" may actually benefit from the frustration of pair programming, although he or she will not appreciate it at the time
pojo-guy
CC BY-SA 3.0
2017-12-13T12:36:48.200Z
2017-12-13T15:13:02.103Z
2020-06-18T08:36:57.023Z
Buffy
<p>I have only lately started allowing (and encouraging!) paired programming, and it is going very well.  The kids enjoy it, and they appear to be learning the material with less pain.  Not everyone has done it yet, however.</p>

<p>This is where I am beginning to sense trouble. I have a difficult major programming lab coming up soon, and my students are psyched to work together on it.  I know that many more of them will want to try pairing, but I worry about odd numbers, and I'm not sure how to handle three students who desire to work together without destroying the benefits that the model can provide.  Is there any way to extend the model of driver and navigator to a trio?</p>

<p>My current intention is for each group to create the same product, with no "splitting" of the work.  One monitor, two students.  Driver and navigator.  These are good and responsible kids, and they can usually find quite productive groupings on their own, though I have no problem stepping in to assist in this if I see things headed in a poor direction.</p>

<pair-programming>
Paired programming with an odd number of students
# Paired programming with an odd number of students

(Asked by: username_0 on 2017-12-13)

I have only lately started allowing (and encouraging!) paired programming, and it is going very well. The kids enjoy it, and they appear to be learning the material with less pain. Not everyone has done it yet, however.

This is where I am beginning to sense trouble. I have a difficult major programming lab coming up soon, and my students are psyched to work together on it. I know that many more of them will want to try pairing, but I worry about odd numbers, and I'm not sure how to handle three students who desire to work together without destroying the benefits that the model can provide. Is there any way to extend the model of driver and navigator to a trio?

My current intention is for each group to create the same product, with no "splitting" of the work. One monitor, two students. Driver and navigator. These are good and responsible kids, and they can usually find quite productive groupings on their own, though I have no problem stepping in to assist in this if I see things headed in a poor direction.

**Tags:** pair-programming


---

## 2 answers

### Answer by username_1 on 2017-12-13. Score: 1

An extension I've come to appreciate is one where you have a "driver", "observer/navigator" and "keeper".

This last role might be considerably more difficult, depending on the lab. The idea is to have someone who keeps track of the *design*. This means that at the start of the lab, the students should all (or just those who start as keepers) dedicate a bit of time to read up online about design patterns in the language they are using. It's important "not to delve too deep". Just a general idea of what "design patterns" means.

Then they begin working. Two out of the three work in usual pair-programming workflow. The third **keeps** in mind the design of the program. As with regular pair-programming, the students should switch roles every now and then. In the case of a trio, they should obviously cycle.

If not all students in the lab are in trios, then an additional for the navigator is to remember design patterns. It should be made clear that it's not their primary task, but that it would definitely help with debugging and maintaining the code.

The added bonus of this extension of pair programming is that students are exposed to design patterns. Seeing as they can sometimes be a complicated matter, starting to tackle them is better done sooner than later.

I have found this solution quite useful in labs about subjects in OOP (the more complex the system, the more important SOLID principles become).


---

### Answer by username_2 on 2017-12-13. Score: 1

tl;dr: This isn't an either/or sort of situation. You have a lot of options for structuring the exercise.

There are a lot of possibilities and which works best depends on the specifics of your situation. Don't lose track of the fact that your goal is educational, however, and not code production. If the students learn but not much code gets produced it can still be a success depending on other parameters. Since I'm going to try to cover a lot of options it will be something of an IFTTT answer.

For all of the cases below it might be best if you don't have one triple or one solo and the rest pairs. It will probably work better for your own learning about this situation if you have, say, *three* triples and the rest paired or three singles. You then get a better picture of how pairing itself differs from other options.

## If you are willing to have some programmers work alone

A few days prior to the exercise let each student make a written bid on whether they want to pair or not. Have them give reasons for their preference. Let them know that their preference may not be able to be honored. Look at the bids and decide based on their reasons and your judgement about what would serve everyone best.

## If you have a single superstar who always makes perfect marks

It is possible that he/she doesn't actually need the practice of this lab so give that person a different task, perhaps as a resource to the remaining pairs, answering questions, prompting, helping you watch over the flock. Someone needs to answer questions as they arise anyway and it might be an opportunity for a person to learn at a more meta level. If your superstar has expressed an interest in teaching eventually this might have additional payoffs for the person. Likewise if he/she is a language lawyer it might help them dig deep into their knowledge on the fly.

## If you have a single struggler (or 3)

You could put him/her into a triple with others not terribly far advanced from that person's state. In this case, be prepared to be a fourth member of that team to help them keep the situation moving and the process easy and friendly. Don't let the struggler avoid the programmer role. Your choice of teams here might have to depend on personal qualities. Don't put him/her with the arrogant monster.

## If the lab is long (say 3+ hours) or if each pair contributes differently to a larger goal

This one is a bit riskier with youngsters but works fine with professionals. Choose teams in any way that suits you (see above) and let the process run for a while (half hour to one hour). It needs to be long enough that switching roles has happened a few times. Then change the teams. Note that some people will move to a team with new code they haven't yet seen (the risk factor). At the switch point, the current driver stays with the code and the navigator(s) find new seats. The current driver for that code just continues after the break and the new navigators(s) spend some time catching up. If a person has been solo or in a triple in one iteration they are in a pair for the next. In many ways this is the most realistic scenario and matches how pairing is done in organizations. The advantage of this in the classroom is that students learn to read and understand new code - a useful skill on its own. However, you may need to map out in advance who the pairs/triples will be for each segment. Each student caries a card with them listing who they worked with and if you want to do peer evaluation, each can mark at the end who they thought was their most effective partner. If they work with at least five others, I would ask them to mark their two most effective partners. Don't ask for criticism of partners, just for who contributed the most. Make sure they know in advance that this will happen - to encourage good behavior. A more elaborate peer evaluation is to also ask why they marked the people they did - who was most effective and why.

## In any case

Don't neglect to set aside time at the end or in the next session to have a retrospective on both the project itself and the process. You could also ask for a written assessment from each student on what worked and what didn't.

## And don't neglect...

Don't lose track of the purpose and benefit of pairing. The driver takes a tactical, microscopic view of the code being produced and the navigator takes a strategic, macroscopic view. Work to keep this concept going as well as possible. It is the essence.

## Additional advice

If you poll the student preferences as suggested above (even in conjunction with a different option) it would be good to announce your decisions a day or so in advance when you can't meet all desires. This gives you a chance to explain (privately) to some why their choice couldn't be honored. "I really need you to ..."

And be clear in your own mind, and let the students know, what is the main goal of this exercise. Is the project itself more important or is learning something about the process. When you have to make compromises do so with that goal in mind.

> **Comments:**
> **username_2**: I intend to continue to think about this and may update it.  
> **username_0**: What is *IFTTT*?  
> **username_2**: IF This Then That: https://en.wikipedia.org/wiki/IFTTT  
> **username_3**: The"perfect student" may actually benefit from the frustration of pair programming, although he or she will not appreciate it at the time  

---

