COS 100: Introduction to Programming

Interim 2022

Pair Programming Guidelines

When working with a partner, you should follow paired programming practices. That means:

• You and your partner should be on a video call, working together synchronously.
• One of you is the driver; the other is the navigator.
• The driver is screensharing and typing into Thonny.
• The navigator is watching the driver, pointing out mistakes (in logic or syntax), and thinking through how the current code fits in with the larger program.
• Both partners should be talking with one another as they go, explaining what they're doing and making suggestions.
• Both partners are responsible for what's happening and the program is shared. If one of you feels that you're not able to get your partner to listen to you, please come talk to me as soon as possible. Ignoring your partner's input is not helpful to your learning or their learning.
• Roughly every 15 minutes (no less than 10, no more than 20 is a good rough rule), driver and navigator switch. Email code to the other person and continue working with roles reversed. Do NOT go through the entire project without switching roles!
• Follow these same ideas in terms of designing your solution even when you're not coding. For instance, you might start your session by sharing a sheet of paper where you sketch out how you'll approach the assignment.
• These guidelines are very concrete and offer ideas for patterns that successful pair programmers follow. The guidelines were developed based on observing paired programming as practiced in real companies.

Paired programming often makes it easier to catch mistakes quickly, and often helps you to design better solutions for the problems you're solving. You should both read through the assignment before meeting, and you can think about how you might go about completing the assignment. However, you should not start coding without your partner (or working on the code at all without your partner); if you do think up an idea and write it down without your partner, go over it together when you next meet. Note that while paired programming can help you catch mistakes more quickly, it won't necessarily help you finish the assignment more quickly than you would by yourself—in general, though, it will help you to learn more than you would by yourself and can help you to avoid too much frustration.

Best practices

Working together often takes some practice, but a few best practices will help things go more smoothly:

• Be respectful of each other's time and work habits: Arrange a time to meet early on (not just right before the assignment is due!). Expect that assignments may take multiple meetings. Set both a start and end time for each meeting. If you're not done by the end time, decide together whether to keep going or meet again another time. When you're together, be focused on the project (not on your phone/email/etc.), but also occasionally take a break. Sometimes five minutes is enough to get you re-energized.
• Work as team: Encourage and support each other as you're working out how to approach the project or how to code up a particular method. Try to avoid being negative about mistakes or thinking about one part of the code as "yours" and the other as "theirs."
• Communicate: The more you communicate, the better this is likely to go. Talk through what you're doing out loud, and ask questions if you don't understand what your partner is saying or doing. Ask your partner if they'd like to drive or ask if your partner would mind if you drive for a bit (when it's a natural point to switch).
• Assume good faith and be understanding: Sometimes, you'll miscommunicate or get frustrated; sometimes your partner will. Try to work through issues and assume that both people want to learn something and get the project done. Pair programming isn't necessarily going to make things faster, but if you view it as an opportunity to learn, you'll likely get a lot out of it.
• Don't talk down: There will likely be points where you understand more than your partner, and points where your partner understands more than you. You and your partner may also have different levels of confidence. Explaining ideas and/or syntax to one another will help both of you learn. Don't spoil the experience by berating or shutting down your partner, and remember to always be respectful of one another.

Logistics for this class

In COS 100, you'll stay with the same partner for a couple projects, and then fill out a feedback form so I know how things went. You have the option of working on your own; I encourage you, though, to choose to participate in pairs because I think you'll often have more fun and develop a deeper understanding of the material.

A few logistical reminders:

• Write both students' names in the comments at the top of your program.
• Submit one copy of your code via Moodle.
• You will receive the same grade.
• If you are turning in the assignment late, both of you will use up one late assignment allowance.

What if we can't work together

I hope it won't happen, but occasionally, something happens that means working with your partner is impossible. Maybe she or he hasn't responded to any of your emails, or doesn't show up for meetings. If this occurs, you can complete the project alone. You should first email me and your partner, and include any code that you two have put together so far; it is not acceptable to simply email your partner and tell her or him that you no longer want to work together—you must include me in this communication. You should comment all of that code to indicate it was done with your partner (e.g., at the top of each function coded jointly, state "This function created with <partner's name>."). You can then finish the coding yourself. You shouldn't take this option just because you're frustrated that you understand something better than your partner, and I'd encourage you to talk to me and your partner before choosing this option. If you and a partner do split, I'll reach out to both of you to see what happened. Generally, you will not have the opportunity to be paired with someone new until the next time others in the class switch partners.

If you run into less serious problems working with your partner and can't resolve them among yourselves, please come talk to me and I will try to help.

As noted in most assignments, you should: start early, ask questions, and have fun when pair programming!