<p>You have to be strict with the rules you set up and monitor the students carefully until it becomes a habit for them.  For instance, if you decide that you want the pair to switch roles every 15 minutes, you could ring a bell or have some other signal for the students to pass the keyboard over, switch seats, or whatever else they would need to do change positions.  Knowing that they will have to switch when they hear the signal will help combat switch resistance.  I have no experience working asking students to engage in pair programming activities outside of my classroom so I can't speak to that.</p>

CC BY-SA 3.0
2017-08-18T20:58:39.590Z
@Buffy The original poster mentioned high school so I was assuming that he is with his students when they are doing their programming assignments.
CS Cheerleader
CC BY-SA 3.0
2017-08-18T21:08:56.273Z
@CSCheerleader. probably not a safe assumption. Also, In the situation you were describing, I'd rather do "teaching by wandering around", nudging, rather than employing my "serious face." I think positive rather than negative enforcement  is likely more effective. I might sit down as a second "navigator" for example and just make the appropriate comments. Note that you can edit your own answers to be more complete.
Buffy
CC BY-SA 3.0
2017-08-19T00:45:25.533Z
I'm going to guess that you would do better with a rule not based on time. If you interrupt the driver's thought process with a bell you set them back.  The driver should be focused like a laser. Since I use small tasks with required tests, the switch can be at the end of a task. If the students task themselves, then at the end of, say, each method written, though even that is a bit artificial. But always switch when the driver is stuck and the navigator has a suggestion.
Buffy
CC BY-SA 3.0
2017-08-19T01:30:41.190Z
The time rule has worked for me.  I do think your idea of having the periods be based on tasks instead of time is a good one and will consider using that  in the future when the opportunity affords itself.
CS Cheerleader
CC BY-SA 3.0
2017-08-22T14:55:56.707Z
'd be happy to have a conversation about the switching of roles in the CSEducators classroom:https://chat.stackexchange.com/rooms/59174/the-classroom. I've also updated my answer to explain the ideas a bit more completely.
Buffy
CC BY-SA 3.0
2017-08-18T14:03:36.543Z
2017-08-19T00:34:57.460Z
2017-08-19T00:34:57.460Z
CS Cheerleader
<p>If you haven't used Pair Programming (PP) before but want to introduce it, there are two additional books you should read for background. They aren't textbooks for your class, but put PP into context. <a href="http://rads.stackoverflow.com/amzn/click/0321278658" rel="nofollow noreferrer">Extreme Programming Explained</a> gives the complete context of PP in the agile development process. Pair Programming is one of the "small scale" practices of  Agile Development - a personal practice, that is used in most agile methodologies. </p>

<p>The second book <a href="http://rads.stackoverflow.com/amzn/click/0201745763" rel="nofollow noreferrer">Pair Programming Illuminated</a> focuses more on PP itself. </p>

<p>Since students may do much of their work outside your view, they need to be convinced that it gives them something or they won't use it. The alternatives seem too enticing to them (e.g. splitting the work...). So the classroom demo suggested here (points 3 and 4) is probably necessary: <a href="https://cseducators.stackexchange.com/questions/3248/techniques-for-encouraging-pair-programming/3251#3251">Techniques for encouraging pair programming</a>. </p>

<p>The problem is that they already have programming habits and they will fall back on those in a pinch unless they see a compelling reason to do something different and develop new habits. The classroom demo can help with that. But you have to play navigator yourself, not just driver, in your demo. </p>

<p>The wisdom of the profession on PP is that the driver takes a microscopic view of the project at hand. If the navigator is behaving correctly he/she will take a broader view, thinking about how what the driver is doing fits into the whole of the app being developed. When you work alone you only get the micro view, which often enough leads you astray. </p>

<p>The navigator is <em>not</em> just an after the fact reviewer, but an active participant. That takes practice. This is the key to making PP productive. You have two minds on the problem and each has a slightly different perspective. </p>

<p>Another advantage is that single programmers often get stuck and have to think for a while about how to proceed. But two programmers seldom get stuck at exactly the same point. That is the time to switch roles. The navigator notices a change in the pace and, perhaps, takes over the driver role for a while. </p>

<p>I have a picture in my head of 10 programmers, each working alone in a cubicle, and each stuck on something, making no progress, but the person in the next cubicle having the key to continue. </p>

<p>Another good practice, if you are always using test first programming (TDD = Test Driven Development) is that one person writes a test, which fails. The other person builds enough of the app to make that test pass and then writes the next (failing) test. The first person takes over to make that test pass, etc. Back and Forth. Clockwork. </p>

<hr>

<p>To understand when and why the driver and navigator roles should switch, think about what a solo programmer does quite naturally. You are programming and have been for a while. You are in the grove. Things are flowing. You are focused like a laser on your work. The solutions are coming naturally. And then... suddenly you hit an obstacle. The next thing isn't obvious. At that point, you naturally widen your focus and look at the wider picture. You eventually "get it" and move back in to continue. Or, perhaps, you take a break. </p>

<p>On the other hand. Consider what is natural for someone looking over your shoulder as you work, making occasional comments on things like naming, or structure. Perhaps reminding you of some method or tool you might employ rather than building something new. They are taking a wider view since they don't have responsibility for the progress. And then, suddenly, they notice a change in the pitch. You aren't making progress and seem puzzled. At that moment, their instinct is to focus more closely on what you are doing to try to resolve the issue. </p>

<p>So, one person widens focus and the other tightens it. That is generally the moment to swap roles as the role is determined by this level of focus. </p>

<p>If you try to switch roles by some arbitrary means, such as time, you will likely lose the advantage of the "dual focus" view of the project. The most likely outcome is either (a) the navigator becomes disengaged altogether or (b) both take the laser view, losing the broader, overall, view of the program. </p>

CC BY-SA 3.0
2017-08-18T14:33:03.290Z
2017-08-22T12:13:25.293Z
2017-08-22T12:13:25.293Z
Buffy
<p>I'm currently reading a book, <a href="http://rads.stackoverflow.com/amzn/click/1940113059" rel="noreferrer">Polymorphism: As It Is Played</a>, which has introduced me to several new instructional ideas.  I am particularly intrigued by Pair Programming, which seems like it could benefit everyone.  However, if I simply describe the idea and tell my high school students to <em>go,</em> I feel like there is a very good chance that it won't really take.  The Navigators might not remain fully engaged, or the kids who are more advanced might just take over the Driver position and not bother to explain what is going on.</p>

<p>How, then, can I handle the introduction?  What are the pivotal ideas that can enable my students to use this tool effectively?</p>

<p><strong>Edit:</strong> I understand that a similar question has been asked <a href="https://cseducators.stackexchange.com/questions/3248/techniques-for-encouraging-pair-programming/3251#3251">here</a>, but my question comes from the perspective of a teacher who is far less familiar with the source material, has never used it in a classroom, and is specifically about the introductory lesson.</p>

CC BY-SA 4.0
2023-11-16T09:52:06.593Z
Have you gained any insight about teaching pair programming since you asked the question in 2017? Personally, I am not a fan of pair programming, as my answer here https://cseducators.stackexchange.com/a/7551/9884 shows (lol). But after trying github copilot for several months, I really like the idea of AI pair programming.
Qiulang 邱朗
CC BY-SA 4.0
2023-11-16T13:25:14.790Z
@Qiulang邱朗 I don't have many insights to characterize. I've been using it on and off for years, and I find that it helps some students tremendously (as in they affirmatively learn more and also produce better work), and it allows some other students to slack off.  My best observation is that it is a difference of difficulty; if both of the students find the work genuinely challenging, then they are often willing to both invest as a team, and they both learn by having a partner. If one is underchallenged, they just take over, and if both are underchallenged, one checks out.
Ben I.
CC BY-SA 4.0
2023-11-16T13:27:18.643Z
@Qiulang邱朗 As a result, I've been using pair programming for labs that really stretch students, but I avoid it on easier labs.  One one particularly daunting lab that I give, I *nearly* require it, and only allow exceptions for students who *really* want to work alone.  This has worked out well, because the lab is very, very hard, and they genuinely need each other to figure it all out.  It is also a good lab to show why, when facing sufficiently complex problems, divide and conquer is a poor team strategy. Students who try to divide and conquer almost never turn in working labs.
Ben I.
CC BY-SA 4.0
2023-11-16T14:49:53.817Z
“divide and conquer is a poor team strategy” interesting! I would suggest you try github copilot and it has student pack, https://education.github.com/pack
Qiulang 邱朗
CC BY-SA 4.0
2023-11-16T16:23:27.607Z
@Qiulang邱朗 I haven't had much use for copilot, to be honest.  (I do use ChatGPT a bunch, however).  And to clarify: much of programming, *most* or programming, can use divide and conquer.  But small, highly intellectually dense problems do not lend themselves to this approach.  Imagine trying to work with a teammate on Programming Koans using a divide and conquer approach, and you will see the problem immediately. I believe that the concentrated intellectual density is the obstacle here. It is similarly so with my very difficult lab: students cannot bring together what they have created apart.
Ben I.
CC BY-SA 3.0
2017-08-18T13:47:03.163Z
I would suggest points 3 and 4 of this post: https://cseducators.stackexchange.com/a/3251/1293. It will take you about one class period, but if carefully done, demonstrates both the technique and its benefits. I think that book describes what might happen _after_ such an introductory lesson.
Buffy
<introductory-lesson><pair-programming>
Introducing Pair Programming
# Introducing Pair Programming

(Asked by: username_0 on 2017-08-18)

I'm currently reading a book, [Polymorphism: As It Is Played](http://rads.stackoverflow.com/amzn/click/1940113059), which has introduced me to several new instructional ideas. I am particularly intrigued by Pair Programming, which seems like it could benefit everyone. However, if I simply describe the idea and tell my high school students to *go,* I feel like there is a very good chance that it won't really take. The Navigators might not remain fully engaged, or the kids who are more advanced might just take over the Driver position and not bother to explain what is going on.

How, then, can I handle the introduction? What are the pivotal ideas that can enable my students to use this tool effectively?

**Edit:** I understand that a similar question has been asked [here](https://cseducators.stackexchange.com/questions/3248/techniques-for-encouraging-pair-programming/3251#3251), but my question comes from the perspective of a teacher who is far less familiar with the source material, has never used it in a classroom, and is specifically about the introductory lesson.

**Tags:** introductory-lesson, pair-programming

> **Comments:**
> **username_2**: I would suggest points 3 and 4 of this post: https://cseducators.stackexchange.com/a/3251/1293. It will take you about one class period, but if carefully done, demonstrates both the technique and its benefits. I think that book describes what might happen _after_ such an introductory lesson.  
> **username_1**: Have you gained any insight about teaching pair programming since you asked the question in 2017? Personally, I am not a fan of pair programming, as my answer here https://cseducators.stackexchange.com/a/7551/9884 shows (lol). But after trying github copilot for several months, I really like the idea of AI pair programming.  
> **username_0**: @Qiulang邱朗 I don't have many insights to characterize. I've been using it on and off for years, and I find that it helps some students tremendously (as in they affirmatively learn more and also produce better work), and it allows some other students to slack off.  My best observation is that it is a difference of difficulty; if both of the students find the work genuinely challenging, then they are often willing to both invest as a team, and they both learn by having a partner. If one is underchallenged, they just take over, and if both are underchallenged, one checks out.  
> **username_0**: @Qiulang邱朗 As a result, I've been using pair programming for labs that really stretch students, but I avoid it on easier labs.  One one particularly daunting lab that I give, I *nearly* require it, and only allow exceptions for students who *really* want to work alone.  This has worked out well, because the lab is very, very hard, and they genuinely need each other to figure it all out.  It is also a good lab to show why, when facing sufficiently complex problems, divide and conquer is a poor team strategy. Students who try to divide and conquer almost never turn in working labs.  
> **username_1**: “divide and conquer is a poor team strategy” interesting! I would suggest you try github copilot and it has student pack, https://education.github.com/pack  
> **username_0**: @Qiulang邱朗 I haven't had much use for copilot, to be honest.  (I do use ChatGPT a bunch, however).  And to clarify: much of programming, *most* or programming, can use divide and conquer.  But small, highly intellectually dense problems do not lend themselves to this approach.  Imagine trying to work with a teammate on Programming Koans using a divide and conquer approach, and you will see the problem immediately. I believe that the concentrated intellectual density is the obstacle here. It is similarly so with my very difficult lab: students cannot bring together what they have created apart.  

---

## 2 answers

### Answer by username_2 on 2017-08-18. Score: 3

If you haven't used Pair Programming (PP) before but want to introduce it, there are two additional books you should read for background. They aren't textbooks for your class, but put PP into context. [Extreme Programming Explained](http://rads.stackoverflow.com/amzn/click/0321278658) gives the complete context of PP in the agile development process. Pair Programming is one of the "small scale" practices of Agile Development - a personal practice, that is used in most agile methodologies.

The second book [Pair Programming Illuminated](http://rads.stackoverflow.com/amzn/click/0201745763) focuses more on PP itself.

Since students may do much of their work outside your view, they need to be convinced that it gives them something or they won't use it. The alternatives seem too enticing to them (e.g. splitting the work...). So the classroom demo suggested here (points 3 and 4) is probably necessary: [Techniques for encouraging pair programming](https://cseducators.stackexchange.com/questions/3248/techniques-for-encouraging-pair-programming/3251#3251).

The problem is that they already have programming habits and they will fall back on those in a pinch unless they see a compelling reason to do something different and develop new habits. The classroom demo can help with that. But you have to play navigator yourself, not just driver, in your demo.

The wisdom of the profession on PP is that the driver takes a microscopic view of the project at hand. If the navigator is behaving correctly he/she will take a broader view, thinking about how what the driver is doing fits into the whole of the app being developed. When you work alone you only get the micro view, which often enough leads you astray.

The navigator is *not* just an after the fact reviewer, but an active participant. That takes practice. This is the key to making PP productive. You have two minds on the problem and each has a slightly different perspective.

Another advantage is that single programmers often get stuck and have to think for a while about how to proceed. But two programmers seldom get stuck at exactly the same point. That is the time to switch roles. The navigator notices a change in the pace and, perhaps, takes over the driver role for a while.

I have a picture in my head of 10 programmers, each working alone in a cubicle, and each stuck on something, making no progress, but the person in the next cubicle having the key to continue.

Another good practice, if you are always using test first programming (TDD = Test Driven Development) is that one person writes a test, which fails. The other person builds enough of the app to make that test pass and then writes the next (failing) test. The first person takes over to make that test pass, etc. Back and Forth. Clockwork.

---

To understand when and why the driver and navigator roles should switch, think about what a solo programmer does quite naturally. You are programming and have been for a while. You are in the grove. Things are flowing. You are focused like a laser on your work. The solutions are coming naturally. And then... suddenly you hit an obstacle. The next thing isn't obvious. At that point, you naturally widen your focus and look at the wider picture. You eventually "get it" and move back in to continue. Or, perhaps, you take a break.

On the other hand. Consider what is natural for someone looking over your shoulder as you work, making occasional comments on things like naming, or structure. Perhaps reminding you of some method or tool you might employ rather than building something new. They are taking a wider view since they don't have responsibility for the progress. And then, suddenly, they notice a change in the pitch. You aren't making progress and seem puzzled. At that moment, their instinct is to focus more closely on what you are doing to try to resolve the issue.

So, one person widens focus and the other tightens it. That is generally the moment to swap roles as the role is determined by this level of focus.

If you try to switch roles by some arbitrary means, such as time, you will likely lose the advantage of the "dual focus" view of the project. The most likely outcome is either (a) the navigator becomes disengaged altogether or (b) both take the laser view, losing the broader, overall, view of the program.


---

### Answer by username_3 on 2017-08-18. Score: 1

You have to be strict with the rules you set up and monitor the students carefully until it becomes a habit for them. For instance, if you decide that you want the pair to switch roles every 15 minutes, you could ring a bell or have some other signal for the students to pass the keyboard over, switch seats, or whatever else they would need to do change positions. Knowing that they will have to switch when they hear the signal will help combat switch resistance. I have no experience working asking students to engage in pair programming activities outside of my classroom so I can't speak to that.

> **Comments:**
> **username_3**: @username_2 The original poster mentioned high school so I was assuming that he is with his students when they are doing their programming assignments.  
> **username_2**: @CSCheerleader. probably not a safe assumption. Also, In the situation you were describing, I'd rather do "teaching by wandering around", nudging, rather than employing my "serious face." I think positive rather than negative enforcement  is likely more effective. I might sit down as a second "navigator" for example and just make the appropriate comments. Note that you can edit your own answers to be more complete.  
> **username_2**: I'm going to guess that you would do better with a rule not based on time. If you interrupt the driver's thought process with a bell you set them back.  The driver should be focused like a laser. Since I use small tasks with required tests, the switch can be at the end of a task. If the students task themselves, then at the end of, say, each method written, though even that is a bit artificial. But always switch when the driver is stuck and the navigator has a suggestion.  
> **username_3**: The time rule has worked for me.  I do think your idea of having the periods be based on tasks instead of time is a good one and will consider using that  in the future when the opportunity affords itself.  
> **username_2**: 'd be happy to have a conversation about the switching of roles in the CSEducators classroom:https://chat.stackexchange.com/rooms/59174/the-classroom. I've also updated my answer to explain the ideas a bit more completely.  

---

