📓 Intro to Pair Programming

As you read this lesson, you and your pair should be together in a voice channel in Discord. You’re both ready to start with pair programming. Read through this lesson together. You may choose to switch reading out loud or read silently and reconvene at the end of the lesson.

Overview

This lesson will revisit the description pair programming and further expand on the responsibilities of the driver and navigator in a pair group. Next we’ll explain some general pair programming etiquette.

Before you and your pair move on to the next lesson you will check-in with each other to communicate a plan for pair programming.

Important terminology in this lesson:

• pair programming
• driver
• navigator
• pair group

The Driver and Navigator in Pair Programming

When pair programming, one person is the driver. The driver is the only person who controls the keyboard and mouse. The driver is writing code and has priority in the pair group to try out ideas.

The navigator is an observer. Anyone who is not the current driver in the pair group is a navigator. In a group of 3 that will mean there are two navigators. The navigator should have their hands off the keyboard and mouse at all times. Even when working remotely when everyone in the pair group has access to their own mouse and keyboard. The role of the navigator is to look out for errors, ask questions, take notes, and maybe look up something relevant for the driver on request.

To simplify, the main role of the driver is to focus on the details while the main role of the navigator is to focus on the bigger picture. Pair programming relies on only one person coding and the other person observing. Two people writing coding at the same time in the same file is not pair programming.

Pairs will switch off so that each person gets to drive frequently.

When you are the driver:

When you're the one in your pair who is driving, your hands are on the keyboard and you are typing code. Here is how to be a communicative driver:

Vocalize what you are thinking and doing.
It is not always clear to your pair what your intentions are just by looking at your code. Vocalize what you are typing in the moment — this also gives you practice using coding terminology. If you are more experienced than your pair, make sure they are following what you are doing. Pause for questions and code at their pace of understanding.

Point or highlight code when speaking about it.
When talking about a piece of code, be sure to point to it or highlight it. You can point if everyone in the group is working in-person. Otherwise, highlight code with your mouse. You can also zoom in or out with Command + or - for Mac and CTL + or - for Windows.

Proactively ask for input or opinions.
Sometimes it's helpful to signal when we want input from others or when we want to leave space for others to talk. You can ask a question such as "what do you think of this approach?" or “any thoughts on what you might do here?”

Be proactive about switching when you are driving.
It's easy as the driver to lose track of how long you have been coding. It tends to feel more awkward for someone to ask for a turn to drive than for you to offer. Be mindful and give your pair opportunities to drive.

When you are the navigator:

When you’re not the driver, it means your hands are off the keyboard. You are observing the driver code in addition to looking for typos, asking questions, and keeping notes.

Do not take over driving without checking in first.
This is very important. When pairing remotely, both pairs have the ability to simultaneously type but only the driver has permission to use the keyboard. While in-person sharing a computer, taking over driving would be the equivalent of taking the keyboard away from your pair. Get permission from your driver before typing.

The driver's choices and experiments take precedence.
You may know the answer or have a great idea but if you're not driving then give your pair space to try things out. We often learn better from trial and error. You will get your chance to try out ideas when it is your turn to drive. You are still welcome to ask questions and point out typos.

Avoid researching something in another window without checking in first.
This one comes up more when working remotely. If you're looking something up then you're not engaged in coding and not listening to your pair. For the sake of learning it is best if everyone in the pair group research together, especially if the driver is stuck and not sure what to do next. It's not helpful for the driver to wait while you research something alone. Invite the driver to research with you.

Don’t always decline the opportunity to be the driver.
Being the driver is challenging. You’re the one controlling the direction of the group and other people are watching while you code. It can be nerve wracking to take over driving, especially if you are not sure what to do. Be kind to the driver and give them a break by taking over driving. Challenge yourself to be outside your comfort zone. Even if your pair is more experienced, everyone should have an equal amount of time driving.

Pair Programming Etiquette

When we pair program, especially remotely, we rely more on direct communication. Needless to say, the means in which humans communicate with others is vast and diverse. We all have cultural social norms and biases that guide how we ask questions or communicate information to others. A lot of our communication is done by body language and nonverbal cues that also vary, depending on culture.

The challenge with working remotely is that we lose access to body language and nonverbal cues from others. To make up for this loss, we have to directly communicate our thoughts and intentions verbally. For many people this is incredibly difficult because direct communication feels rude or presumptuous. Direct communication does sometimes mean asking for clarity at the cost of comfort.

Be patient and kind with each other as you work together.

General Good Strategies:

Avoid jokes.
You and your pair don’t really know each other yet. Remember too that Epicodus is a workplace. Especially avoid self deprecating humor or making jokes in response to awkwardness. Self deprecating humor puts onus on your pair to make you feel better which can be emotionally draining for them. Making jokes in response to awkwardness is risky because it can invalidate the situation or other's feelings.

Take turns speaking and allow room for silence.
Turn-taking is a universal method that humans use to communicate with one another. It relies on being aware when it is your turn to speak and allowing space for others to speak.

You and your pair may have different social norms regarding communication. Also, since we’re learning, you and your pair will need time to think before speaking.

Allow room for silence. Oftentimes we feel uncomfortable in silence especially if we are with people we don’t know well. However, when pair programming (especially remotely when it is difficult to see body language) we need to be comfortable with silence. Allow your pair(s) time to think and respond.

Ask permission to speak.
It can be helpful and polite to ask to speak before doing so, especially if you are not sure what your pair is thinking or doing. This helps to insure you are not accidentally interrupting anyone; even during periods of silence. Ask such questions like “Are you open to suggestions?” or “May I say something?” or “When would be a good moment for me to ask a question?” Give your pair an opportunity first to say what's on their mind or to let you know that they need more time to think.

Recognize indirect communication
Sometimes direct communication makes us feel uncomfortable because we don’t want to be rude. In these moments we may rely on indirect ways to ask for what we want. Indirect communication generally avoids answering with hard “yes” or “no”.

For example, someone in the pair group might say “Coding this part looks really fun!” For someone who communicates directly, this doesn’t sound like a request to be the driver. This person may not be comfortable or not used to asking directly, “This part looks really fun to code. Can I drive?”

If you tend to be a naturally direct communicator, recognizing when someone might be communicating indirectly will be challenging. The important thing right now is to recognize that indirect communication is not wrong and it's not in any way a sign of timidness. Many languages in the world have an indirect communication style. Even in western culture, women are more socialized to speak indirectly more so than men.

When working remotely:

Turn off your microphone when you are not speaking. Some ways to do that:

• Discord's keyboard shortcut to mute: control + shift + m. Though this is easier for pairs who are not driving.
• Discord's push to talk option. You might find this a better option for you if you are driving. Push to talk means you are automatically silenced unless you push a button. You can follow the instructions provided by Discord if you're interested in this option.

It's okay to ask someone to silence themselves.
Sometimes we forget that our mic is on. Oops! It's generally considered polite to let someone know that their mic is on because it protects them from accidentally saying something they didn’t want others to hear. Kindly let your pair know their mic is on if extra noise is coming in through their mic while not talking.

Clarify if someone is trying to speak.
Sometimes we forget to unmute ourselves when we're talking. If you suspect that might be the case during a particularly long stretch of silence from your pair, it's okay to say something like: "If you are talking, I cannot hear you." \

Turn on your camera so others can see you.
This might not be feasible for everyone though. Turning on your camera takes up a lot of internet bandwidth so don’t keep your camera on if it is slowing down your connection.

If you can have your camera on while working, there are a number of advantages to this approach — it's easier to see and respond to your pair and there's more opportunity to empathize and get to know each other. Video calls also help encourage accountability.

FAQ

Q: “What if the driver is doing something I know won’t work or is wrong?”
A: Let the driver try it anyway. Who knows, you might learn something new. When learning something new it is better to see the failed results of an attempt than to always be told what to do. Give the driver space to try even if you think they will fail.

Q: “What if I am the driver and I don’t know what to do?”
A: That's okay and it is important to communicate that with your pair. Being a developer means being comfortable with saying “I don’t know but I can find out.” Perhaps you and your pair could revisit a previous lesson that might help or look something up together? Do your best to verbalize what you don’t understand.

Check in with your Pair

Every time you start a class session, and especially when working with a new person, you should both talk to establish an agreed upon set of expectations when pair programming. Here are some questions to discuss to get started:

1. How comfortable are you with the material?
   We all need to be honest if we are unfamiliar with something or don’t understand the material. Remember that having a fixed mindset, counter to having a growth mindset, is preoccupied with appearing knowledge to avoid looking foolish. Whereas a person with a growth mindset is not embarrassed by not knowing. \

2. What will decide when it is time to switch driver and navigator roles? Some ideas include:

   • Switching after a certain amount of time has passed. Typically 20 to 30 minutes.
   • Split the class session in half (or thirds for three people in a pair group) and be the driver during your half.
   • After a certain number of lessons.

   There are no hard rules for when to switch off in pair programming. The important thing is to just have an agreed upon plan for when it happens.

1. How will group reading be done? You may have already decided this but some ideas include:
   • Taking turns reading out loud. Also known as “popcorn reading.” This is a very effective strategy because it forces you to practice verbalizing coding terminology. When you are not the one reading you can take notes for yourself or write down questions for later.
   • Read silently but reconvene at scheduled check-in points. This could mean checking in at the end of a lesson or every section in a lesson.