4
$\begingroup$

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.

$\endgroup$
  • $\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 Aug 18 '17 at 13:47
2
$\begingroup$

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.

$\endgroup$
1
$\begingroup$

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.

$\endgroup$
  • $\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$ – CS Cheerleader Aug 18 '17 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 Aug 18 '17 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 Aug 19 '17 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$ – CS Cheerleader Aug 19 '17 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 Aug 22 '17 at 14:55

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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