Page 1: Pair Programming
Unit 1, Lab 2, Page 1
On this page, you will learn about collaborating by using pair programming.
In the early days of computers, programming was something you did alone. You planned the program in your head, and then you sat down and wrote the code.
The programs people write these days are far too complicated for that. Graphical user interfaces, interacting with servers on the Internet, internationalization, security against malware attacks, and many more requirements are part of a serious software development effort, and a program is likely to have hundreds of authors.
This means that collaboration skills are as important as coding skills today. Even if you don’t end up working as a programmer, collaboration is part of most jobs.
We’ll watch this video in class together, but here it is in case you want to watch it again:
There are several ways to organize a collaboration. In this course, you’ll use a collaboration technique called pair programming—writing computer programs in teams of two. One partner, the driver, controls the computer. The other, the navigator, helps the pair stay on track and makes sure the code the driver is writing fits into the overall plan. The navigator is also in charge of reading the lab pages out loud. Aim for equal time in each role, switching about every five minutes.
How not to do pair programming:
The biggest mistake in pair programming is to think that the driver is in charge because their hands are on the keyboard and mouse. The navigator isn’t watching the scenery go by; they’re navigating—they should be thinking about how the code is going to work and watching to make sure the driver doesn’t make mistakes. It’s surprisingly hard to enter code perfectly and it’s a lot easier to notice mistakes when you’re not busy driving.
The driver should, of course, also keep their brain fully engaged. If your navigator is telling you something that you think is wrong, stop and have a convesation about it. Real pair programming is not just two people taking turns doing the work; it’s getting the benefits of having two people both paying full attention.
One tip: If you’re navigating and you’re not sure how to proceed, ask to switch and drive while your partner navigates for a while. And conversely, if you’re driving but you think the navigator may be lost, it’s better to suggest a switch than to just start navigating on your own.
How to collaborate in pair programming
Keep talking. The navigator should explain the reason for using each block. The driver should make sure they understand what the navigator is asking for and should always feel free to ask questions. What about doing it this other way? How does this program avoid such-and-such bug? Don’t we have to deal with this requirement and that requirement at the same time? We’re pretty much repeating this other piece of code over there; could we hide that code in a block and use the same block in both places? And so on.
Listen. Try to understand each other’s thinking before you disagree.
Work as a team. If you find yourself being defensive about feedback, remember that nobody’s code is perfect right away. It’s the navigator’s job to find problems in the driver’s code, and when you switch places, the new navigator will repay the favor. You’re a team, not a competition.
Work toward consensus. Don’t bargain; if you have disagreements about how something should be done, don’t say “well, you can do this your way if I can have this other thing my way.” Both partners should listen to each other’s reasons and work together to find a solution that meets both needs.
Speak your mind and work out your differences. That doesn’t mean you should try to disagree, but if you do, you can still be friends. Work out the conflict by listening and understanding each other, rather than by giving in just to end the argument.
Regardless of experience, take turns. Don’t let the more experienced programmer overwhelm the other partner. Make sure both partners are comfortable contributing, in either role. A group is almost always better at problem-solving than any of the people in the group is alone.
In the first unit, we’ll use these symbols to remind you to switch roles at specific points in the lab. After this unit, you’re on your own to be sure to switch about every five minutes.
If you are working with a partner, make sure you both have access to the project. It is your responsibility to make sure that you can access the project if your partner is absent the next day.
Your teacher will hand out instructions for the Lost on the Moon game.
This is a non-programming problem that you will work on in pairs in order to practice the ideas listed above.