Blog Post

Pair Programming

I hope you all have had a great start to the year. Things have been very busy here between teaching this new subject and co-advising a second club (our math team is so much fun and we keep getting new interest!), but I’ve found some time to think about what I want to talk about this month—that is, some teaching methods that have gone well for me in this course.

The first method that both my students and I have enjoyed is pair programming. The general idea is that instead of having each student working on his or her own program, they work on it in pairs (or triads, if necessary). It runs along the line of: “two heads are better than one.”

The way that I framed it after talking to a colleague was in terms of driving. In each pair, we have a driver and a navigator. Before we first tried this, we discussed what the responsibilities of each person would be in a car. A driver is responsible for the wheel, gas, and brake—essentially working with the hardware and user interface of the car. The kids then made the deduction that the driver in their group was responsible for using the mouse and keyboard and interacting with App Inventor (our programming environment) to create the app. In a car, the navigator is responsible for guiding the driver with directions, managing money for tolls, etc. In our class, the navigator is responsible for reading the text instructions, watching video instructions, and explaining/checking the code that the driver is creating. Whenever we do pair programming, I have the students switch roles roughly every 10 minutes.

One of the benefits of having two people working on the same program is that it gives two sets of eyes and ideas. We’ve all worked on something where we can’t find what’s wrong, but someone else can come along and spot it quickly. In addition, when the students are asked to create enhancements for apps, having ideas from two people gives them more to choose from and more to add to their app.

Another benefit is that it builds teamwork and cooperation, skills that most people use in their lives. Each person is needed to make the team complete. Without the driver, a program isn’t getting created; and without the navigator, the driver is lost. I started this out by letting the students choose their partner for the first unit in order to get them comfortable with the idea of sharing responsibilities. For the next unit, I switched seats. They were a little upset, but they have been working well together. My plan is to switch them each unit so that they get a chance to work with different ideas and levels of programming background. By the time we do the programming piece of the AP exam, they will have an idea of who they might want to collaborate with.

There are a couple things you want to look out for when doing this. First, there may be students who would rather just work alone. I can completely relate to this, as that’s exactly what I wanted to do when we used it during my summer training. I wanted to make sure I had an understanding of each lesson, and to me the best way to do that was to make the program myself. Another part of this is that some students are just shy (I was very shy in high school too!), so you have to be mindful of who you group them with. My students have been much more receptive to this way of programming, so that hasn’t been an issue for me. One issue that has come up has been students who see this as an opportunity to slack off while their partner works on a program. In those situations, it has been effective to switch their role to a driver, forcing them to contribute. But it’s something I make note of when grading their programs. Finally, it is important to get the students into a routine of sending the program to their partners at the end of class. That way, each partner can work if they need to access it in class when someone is absent or at home when they are doing their write-up.

Overall, pair programming has gone very well with my students. I was worried that it wouldn’t since I was hesitant to use it myself over the summer, but they have responded well to it. After only two classes working together, my new groups are working well. They are asking each other questions before asking me (which is great!), and I’m not the only “expert” in the room (not that I’m an expert, they show me new things all the time!). It’s fantastic to see them becoming problem solvers.

 

Noah Mealy works at Conard High School in West Hartford, Connecticut. He has taught math courses from pre-algebra to calculus, but this will be his first year teaching computer science. He is teaching AP Computer Science Principles using the Mobile CSP curriculum. Noah is also the advisor of Conard’s Game Club and co-advisor of the Math Team. He is excited to blog for CS for All Teachers, and welcomes your comments at noah_mealy@whps.org.

 

Comments

Permalink

Profile picture for user Itchcode
Submitted by Jason Rukman on Wed, 11/16/2016 - 12:48 pm EST

Another thing I always tell students. Pair programming is borrowed from real programmers from places like Google, Apple and Microsoft! We even use pair programming during employee interviews to find out how well we are able to work with a new prospective employee.

You can go out to wikipedia to learn about some of the stats of pair programming: https://en.wikipedia.org/wiki/Pair_programming