Pair Programming Code of Coduct
Pair programming is an important part of what you’ll do
this semester. For many of you, this is the first course in which pair
programming is a requirement, and this document provides guidelines to
help you become a good partner. It serves as a corrollary to
the official CS 40 rules
for pair programming, specifying and clarifying what it means to
be a good pair programmer. Much like
the Course Coding Standards, this
document is crucial to everyone’s success in CS 40. You should refer
back to it during the semester as you hone your skills as a pair
programmer.
Perhaps the most important part of being a pair programmer is learning to empathize with your partner, and to respect how they learn; how they can best work with you, and you with them. Our goal is to provide concrete, useful tools to practice mutual respect and to begin thinking as a pair programmer. We hope that by being thoughtful in the JCC, we will create a place in which everyone can focus on learning.
These guidelines are written by CS 40 students and are based on their experiences with pair programming. We hope this document will help you build better partnerships and help address any pair programming issues you may face.
For this to happen it's essential that every partner participates fully in every phase of the work. Your goal is to help your partner succeed and grow. Take the time to listen to each other, to teach each other, and to make sure each partner gets practice not just with things they already do well, but especially with the things they do not.
Talk about expectations before starting technical work.
Ask your partner how they learn best — How do they approach planning? How much code do they normally write before compiling? How will you decide when to switch places at the keyboard? What times of day do you work best?
Check in with your partner regularly.
Before beginning a work session, perhaps ask your partner how they’re doing. If you’re at the keyboard, make sure they are following along with you. After finishing a chunk of the project, check in with a question like "How do you feel about what we just wrote?"
Stay healthy.
It's easy to forget about some basic human needs when you're coding for hours in the JCC. Make sure you and your partner take breaks to eat, sleep, and even just get away from the project for a little bit. Not only will you be healthier, you'll probably alleviate stress-induced crankiness and even solve problems faster when you get back.
(Note: If you have a more serious health issue, do contact the course staff. We're here to help!)
Don’t take the keyboard from your partner.
Though you may not intend it, by taking the keyboard away from the person typing, you are implicitly saying to your partner, “You are not capable of learning this,” and are prioritizing finishing the project over making sure that both people learn and understand. Your goal isn’t just to get the project over and done with — the true goal is for you to learn the content of the project and how to solve problems collaboratively.
Don’t physically divide the space between you.
Both partners should be able to see the screen clearly at all times. For example, the computer towers in our labs can create an awkward barrier between you and your partner. This barrier can keep the partner who’s not typing from feeling fully engaged with the programming.
Listen.
Some people talk a lot, often at the expense of their partner's ideas. If you find yourself doing most of the talking, or speaking over your partner, whether working separately or asking TAs questions, you should stop and take a breath. Really ask your partner how they're doing and what they think.
Respect your partner’s time.
Both partners must be present to write code for all CS 40 projects. Showing up on time is essential to having a good pair programming experience. Remember to compromise and be conscientious of your partner’s needs. You may have to work at non-ideal times, such as early in the morning or late at night.
Find a way to share code between partners.
All projects in this class are submitted from one account, but both partners should have access to the code at all times. Develop a system to ensure everyone has the most recent versions of your project. (Note: public github repos are not an option here.)
Your partner is your first resource.
While coding, ask your partner any questions you have before turning to another group, a TA, or the internet. If you turn to another source first, it can seem like you are assuming that your partner doesn’t know the answer. That being said...
Respect your partner’s instinct to ask for help.
While your partner should be your first resource to look for help, there’s no harm in reaching out to a TA when you’re both stumped.
Don’t feign surprise.
For example: “You don’t know what the stack is?!” Acting surprised when people say that they don’t know what something is has no educational or social benefit. Usually when people do so, it is to make themselves feel better and others feel worse. We hope to create an environment where everyone feels free to ask questions without fear of embarrassment.
Always refer to the code as "ours."
Use plural, first person possessive words when talking about your project. For example, instead of asking why my function isn’t working, ask why our function isn’t working. All code that you write is written by both people.
However, problems may arise that are beyond what you are expected to handle on your own. When that happens, we encourage you to ask for help promptly. The failure of your partner to abide by this Code of Conduct makes it impossible for you to complete the assignment we've given, and consequently they would be violating both the course guidelines and the Tufts rules of academic integrity. You have a right to expect that your partner (and everyone else involved with CS 40) treats you with respect, and if they don't we want to know.
There will never be any negative consequence to you for reporting concerns such as these.
Perhaps the most important part of being a pair programmer is learning to empathize with your partner, and to respect how they learn; how they can best work with you, and you with them. Our goal is to provide concrete, useful tools to practice mutual respect and to begin thinking as a pair programmer. We hope that by being thoughtful in the JCC, we will create a place in which everyone can focus on learning.
These guidelines are written by CS 40 students and are based on their experiences with pair programming. We hope this document will help you build better partnerships and help address any pair programming issues you may face.
Goals for your work as a team
The main goal of your work is not to complete a project or to get a good grade: the goal is for all partners to learn by doing, by participating in the entire process of completing the assignment.For this to happen it's essential that every partner participates fully in every phase of the work. Your goal is to help your partner succeed and grow. Take the time to listen to each other, to teach each other, and to make sure each partner gets practice not just with things they already do well, but especially with the things they do not.
Why Pair Programming?
- Learning to work with other programmers is an important skill. Pair programming is a common practice in programming careers, and it's something you will likely do if you pursue research work.
- You will learn a lot from your partners, both in the field of Computer Science and elsewhere.
- We can give you bigger, more interesting assignments if we know there are two people working on them.
- Pair programming builds community in the department.
- CS 40 is a difficult course, and the programming projects take time and energy. Your partners will share the load and provide emotional support.
Guidelines for Pair Programming
Talk about expectations before starting technical work.
Ask your partner how they learn best — How do they approach planning? How much code do they normally write before compiling? How will you decide when to switch places at the keyboard? What times of day do you work best?
Check in with your partner regularly.
Before beginning a work session, perhaps ask your partner how they’re doing. If you’re at the keyboard, make sure they are following along with you. After finishing a chunk of the project, check in with a question like "How do you feel about what we just wrote?"
Stay healthy.
It's easy to forget about some basic human needs when you're coding for hours in the JCC. Make sure you and your partner take breaks to eat, sleep, and even just get away from the project for a little bit. Not only will you be healthier, you'll probably alleviate stress-induced crankiness and even solve problems faster when you get back.
(Note: If you have a more serious health issue, do contact the course staff. We're here to help!)
Don’t take the keyboard from your partner.
Though you may not intend it, by taking the keyboard away from the person typing, you are implicitly saying to your partner, “You are not capable of learning this,” and are prioritizing finishing the project over making sure that both people learn and understand. Your goal isn’t just to get the project over and done with — the true goal is for you to learn the content of the project and how to solve problems collaboratively.
Don’t physically divide the space between you.
Both partners should be able to see the screen clearly at all times. For example, the computer towers in our labs can create an awkward barrier between you and your partner. This barrier can keep the partner who’s not typing from feeling fully engaged with the programming.
Listen.
Some people talk a lot, often at the expense of their partner's ideas. If you find yourself doing most of the talking, or speaking over your partner, whether working separately or asking TAs questions, you should stop and take a breath. Really ask your partner how they're doing and what they think.
Respect your partner’s time.
Both partners must be present to write code for all CS 40 projects. Showing up on time is essential to having a good pair programming experience. Remember to compromise and be conscientious of your partner’s needs. You may have to work at non-ideal times, such as early in the morning or late at night.
Find a way to share code between partners.
All projects in this class are submitted from one account, but both partners should have access to the code at all times. Develop a system to ensure everyone has the most recent versions of your project. (Note: public github repos are not an option here.)
Your partner is your first resource.
While coding, ask your partner any questions you have before turning to another group, a TA, or the internet. If you turn to another source first, it can seem like you are assuming that your partner doesn’t know the answer. That being said...
Respect your partner’s instinct to ask for help.
While your partner should be your first resource to look for help, there’s no harm in reaching out to a TA when you’re both stumped.
Don’t feign surprise.
For example: “You don’t know what the stack is?!” Acting surprised when people say that they don’t know what something is has no educational or social benefit. Usually when people do so, it is to make themselves feel better and others feel worse. We hope to create an environment where everyone feels free to ask questions without fear of embarrassment.
Always refer to the code as "ours."
Use plural, first person possessive words when talking about your project. For example, instead of asking why my function isn’t working, ask why our function isn’t working. All code that you write is written by both people.
When you're not holding the keyboard
In pair programming, usually only one person can type at a time. Here are some suggestions for the other person:- If you have a spare USB keyboard, plug it in and keep it handy. That way you can switch with your partner without passing the keyboard (a procedure I have always found awkward).
- If you're not holding a keyboard, hold a pencil and a piece of paper.
- Keep your lips moving. If you understand what's going on, keep up a running commentary. If you don't understand what's going on, ask questions.
- If you're debugging and your partner is changing code, make a note of other parts of the program (in the same module or in other modules) that will have to be changed. For example, if your program does arithmetic, and you decide the math is wrong, if your partner is replacing "old math" with "new math", make a note of all the other places you'll have to inspect for "old math."
- If your partner is working on the definition of a data structure, draw a picture of it.
- If your partner is writing down a struct definition, insist on a short same-line comment documenting each field.
- If your partner is working on an an algorithm, draw pictures of any relevant data structures and think of simple and edge cases.
- If your partner is writing new code, or revisiting old code that doesn't work, write down how to test it.
What to do when there's trouble
Working with other people can be very rewarding, but it can also be challenging. You are expected to make a good effort to build an effective team. It's not always easy, but you will learn a lot about how to work collaboratively.However, problems may arise that are beyond what you are expected to handle on your own. When that happens, we encourage you to ask for help promptly. The failure of your partner to abide by this Code of Conduct makes it impossible for you to complete the assignment we've given, and consequently they would be violating both the course guidelines and the Tufts rules of academic integrity. You have a right to expect that your partner (and everyone else involved with CS 40) treats you with respect, and if they don't we want to know.
There will never be any negative consequence to you for reporting concerns such as these.