**Pair programming guidelines** --- For some labs and in-class activities this term we will be using a technique called [pair programming](http://collaboration.csc.ncsu.edu/laurie/Papers/Kindergarten.PDF). Here’s how it works: - You and your partner should be at the same computer, working side by side. - One of you is the **driver** and controlling the keyboard; the other is the **navigator**. - The driver is typing and controlling the mouse. - 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 and algorithm design 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. Driver slides keyboard over to navigator. (If it’s not possible to just slide the keyboard, check and make sure that the space you’re working in is big enough for both of you to see the code and work together.) - 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](https://www.mathcs.bethel.edu/yang/teaching/carleton/resources/zarb_ppg_2014.pdf). 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 you mind if you drove 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 You’ll stay with the same partner for a few weeks, and then fill out a feedback form and get assigned a new partner. 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 need to use late days. # What if we can’t work together? 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. I hope it won’t happen, but occasionally, something happens that means working with your partner is impossible. Maybe they haven’t responded to any of your emails, or don’t show up for meetings. What should you do if this occurs? 1. **Talk to me, either in person or over email**. You can do this either after attempting to settle things with your partner, or as a first step if you do not feel comfortable going to your partner first. What will talking to me accomplish? - Help you gain perspective on the situation. - Help strategize talking points with your partner. - If necessary, a conversation between you, your partner, and me to try and resolve the issues. 2. **If all else fails, you can complete the project alone**. You do not need my permission to do this. You should comment all of that code to indicate it was done with your partner (e.g., at the top of each method coded jointly, state “This method created with .”). 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. *Acknowledgments: These guidelines are based on guidelines written by Jed Yang of Bethel University and modified by Sneha Narayan of Carleton College.*