I'm currently reading a book, Polymorphism: As It Is Played, 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, 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.

  • $\begingroup$ I would suggest points 3 and 4 of this post: 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. $\endgroup$
    – Buffy
    Commented Aug 18, 2017 at 13:47
  • $\begingroup$ 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 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. $\endgroup$ Commented Nov 16, 2023 at 9:52
  • $\begingroup$ @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. $\endgroup$
    – Ben I.
    Commented Nov 16, 2023 at 13:25
  • $\begingroup$ @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. $\endgroup$
    – Ben I.
    Commented Nov 16, 2023 at 13:27
  • $\begingroup$ “divide and conquer is a poor team strategy” interesting! I would suggest you try github copilot and it has student pack, education.github.com/pack $\endgroup$ Commented Nov 16, 2023 at 14:49

2 Answers 2


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

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.


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.

  • $\begingroup$ @Buffy The original poster mentioned high school so I was assuming that he is with his students when they are doing their programming assignments. $\endgroup$ Commented Aug 18, 2017 at 20:58
  • $\begingroup$ @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. $\endgroup$
    – Buffy
    Commented Aug 18, 2017 at 21:08
  • $\begingroup$ 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. $\endgroup$
    – Buffy
    Commented Aug 19, 2017 at 0:45
  • $\begingroup$ 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. $\endgroup$ Commented Aug 19, 2017 at 1:30
  • $\begingroup$ 'd be happy to have a conversation about the switching of roles in the CSEducators classroom:chat.stackexchange.com/rooms/59174/the-classroom. I've also updated my answer to explain the ideas a bit more completely. $\endgroup$
    – Buffy
    Commented Aug 22, 2017 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.