Pairing remotely comes with a unique set of challenges. When we communicate in-person, we rely on visual cues such as facial expressions. We use these cues to let us know when we should be listening, when we can take a turn to talk, and whether the person we are talking to is responding positively or negatively. However, when using voice and text channels on Discord, we don't have access to visual cues.
This lesson covers best practices for pairing remotely, including how to be a good pair and how to advocate for yourself if you are not having a good pairing experience. We'll also discuss some techniques and approaches that can potentially improve your remote pairing experience. A lot of what we cover applies to in-person pairing as well.
VS Code offers lots of great tools to make pairing remotely very close to the in-person experience. When you join a Live Share session in VS Code, you'll see an grey thumbtack in the upper right corner. Click on thumbtack and it will turn green. Your view in the Live Share session will then automatically follow the cursor of your pair as they navigate through the project. If you have more than one other person in your Live Share session, VS Code will ask first who you would like to follow.
Share your screen with Discord's Go Live streaming feature. This option is more simple than setting up a Live Share session in VS Code but comes with some drawbacks. For one, alternating driving between pairs would be slower. However, you may find this the better option when the curriculum in Learn How to Program is not asking you to work on a project. Follow the instructions from Discord to start a streaming session. Be aware that Discord will be sharing your entire screen. Be sure there is no sensitive or private information on your desktop or in your browser bookmark bar.
Set up a schedule for alternating driving. We recommend alternating every fifteen or twenty minutes. You can determine your schedule at the beginning of the day. Then stick to your schedule.
Set up scheduled checkpoints during reading for discussion. Sometimes in the Learn How to Program curriculum, there are long stretches of reading without coding. Sometimes, pairs prefer to read this material together by taking turns reading out-loud. More often, pairs prefer to read in silence. In the latter case, it is harder to know where your pair is at in the material since you are not sharing a screen. If you and your pair prefer to read in silence, set up checkpoints for when you both will stop reading, wait for the other to catch up, and discuss the material you've read so far before continuing.
Take turns speaking and give your pair time to respond. Turn-taking is a universal method that humans use to communicate with one another. If everyone were always talking at once, we wouldn't be able to listen to each other. Turn-taking means being aware of when it's your turn to speak — and also allowing space for others to take a turn to speak. It's more difficult to do without visual cues. We can allow for turn-taking by creating a longer pause when we stop speaking. This gives others an opportunity to take a turn to speak. For many, this may involve taking a longer pause of silence than they are used to, especially when working together remotely.
Don't make assumptions about your pair or others. This is always important, but it's especially important to evaluate any assumptions we make about people we are interacting with remotely. For instance, we can't make an assumption about someone's gender based on their name.
Be careful when making jokes. Not everyone has the same sense of humor. A joke that may seem innocuous to one person may be offensive to another. Add in the fact that we can't see the reactions of the people we are working with remotely and it's easy to hurt someone's feelings.
When you're the one in your pair who is driving, your hands are on the keyboard and you are typing code. Here is advice on being a communicative driver.
Vocalize what you are thinking and doing. This is true even if we were in an in-person setting. It is not always clear to your pair what your intentions are just by looking at you code. Vocalize what you are typing in the moment — this is a great way to also practice any coding terminology you have learned so far. 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.
Highlight code you are pointing to. When talking about a piece of code, be sure to highlight it so there is no miscommunication with your pair. Since we're not in-person, we don't have the advantage of just pointing to our screen. You can also zoom in or out with Command + or - for Mac and CTL + or - for Windows.
Be proactive about turn-taking. Sometimes creating extra silence for turns isn't enough or you might want to be more proactive about taking turns. You can signify that you are giving space for turn-taking by asking a question such as "what do you think of this approach?" You can also adopt an auditory signal such as "over" (used by radio operators) or even a custom word of your own.
Be proactive about switching when you are driving. You are responsible for keeping track of how much you are driving — not your pair. Keep in mind that it's more awkward for someone to ask to drive than it is for you to be aware of when you should make the switch. Some pairs may feel uncomfortable asking to drive, so it's important not to assume that their silence means they are fine if you've been driving too long.
When you're not the one in your pair who is driving, it means your hands are off the keyboard. You are observing your pair code, looking for typos, and discussing ideas for the project.
Do not take over driving without checking in first. This is very important. When pairing remotely, both pairs have the ability to type simultaneously. However, only the driver should be typing at any given time. If you are not driving and you'd like to try something, first ask the driver. It's not acceptable to simply start typing or just say "Here, let me try something." That would be like tearing the keyboard away from someone if you were pairing in-person.
The driver's choices and experiments take precedence. You may know the answer or have a great idea, but if you're not driving, it's important to give your pair space to try things out. That gives everyone a chance to learn. You will get your chance to try out ideas when it is your turn to drive. You are still welcome to make suggestions and point out typos.
Listen with the intent of listening, not responding. Being an active listener is important and one of the most important skills you can hone as an effective communicator.
Avoid researching something in other window without checking in first. If you're looking something up in another window, you're not engaged in coding and not listening to your pair. In an in-person setting, you would research something together since you share a screen. Offer a suggestion that you and the driver pause together to research.
This one can be a bit more annoying to implement, especially when you're driving, but muting your mic is an effective way to let others know you aren't taking a turn. Likewise, unmuting your mic is a signal that you'd like to take a turn to speak. To make this process a little easier, here are some options:
Discord's keyboard shortcut to mute: control + shift + m. It's easier for pairs not driving to implement this technique — if you are driving, this can impede your workflow.
Discord's push to talk option. You might find this a better option for you if you are driving or unable to find a quiet place to work. Push to talk means you are automatically muted 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 mute themselves. Sometimes we forget that our mic is on. Oops! Politely ask your pair to mute themselves if extra noise is coming in through their mic while they're not taking a turn to talk.
Sometimes we forget to unmute ourselves when we're talking. If you suspect that might be the case during a particularly stretch of silence from your pair, it's okay to say something like: "If you are talking, I cannot hear you."
Get on a video call with your pair. We encourage students to get on a video call with their pair instead of using Discord's voice channel. 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 and professionalism. You can get on a video call with Discord with the following steps.
Not all students will be able to get on video calls. Internet bandwidth, monitor screen size, and personal preference are all reasons a video call might not work for your situation.
Respond with complete messages in text chat and use emotes. It's often hard to tell the tone of a person just from text alone. Our brains tend to interpret the tone of text as indifferent or sarcastic, especially if we've been struggling with code all day. We can take extra steps to convey our tone in text by writing out complete messages and using emotes. As an example, if someone says "I'd like to take a 15 minute break," replying with "k" can mistakenly come off as indifferent. Instead, respond with something more like: "Okay, sounds good! I'll take a break too. =)"
Don't eat food on screen and while unmuted. Hearing the noises of someone else eating food while trying to concentrate on code is distracting. Just the same, seeing someone eat food on a video while trying to focus in a group meeting can be just as distracting. If you are eating while in class (if it is more than just a snack), this can also feel like you are not fully participating to your pair. Please refrain from eating during meetings or while pair programming, especially on screen and unmuted. Instead, take a break to eat.
Speak up if the pairing experience isn't working for you. If you are having a difficult time communicating, let your pair know. There's a good chance they aren't aware of how you're feeling. They also may not be aware of things they are doing that may be impeding the pair experience — for instance, if they are excited about trying to solve a problem, they may have lost track of time and forgotten to exchange drivers. Make sure to use "I" instead of "you" language to address the issue. For instance, you might say, "I feel like I'm not driving much today and I'd like to drive more." It would be less constructive to say: "You're driving too much and you won't give me a chance to try my approach."
Listen to your pair. If your pair brings up a concern or an issue, listen to them. If the concern is brought up constructively, take it as an opportunity to improve your communication and pairing skills. Remember, your ability to communicate is an essential skill to landing a job.
If necessary, check in with your instructor. If you are having issues pairing that can't be resolved through direct communication, check in with your instructor. Your instructor will need you to be more proactive about bring issues to them in the remote classroom. Compared to an in-person classroom, they don't have the advantage to pick up on body language between pairs or overhear classroom talk. Your instructor can help resolve the issue. Sometimes this means mediating between pairs. In rare cases, it may be necessary to switch pairs or solo for the rest of the day. Please report any hostile or discriminatory behavior. Instructors will make sure the information you share remains anonymous.
Do not record any meeting with staff or students. Although we are working online and using cameras and microphones to communicate, that is not explicit consent to record someone without their knowledge. Epicodus Staff do not give permission to be recorded. Do not record Scrum, Career Services Info Sessions, or any meetings involving Epicodus Staff. These meetings will not be recorded by Epicodus Staff.
Do not record guest lunch speakers. Epicodus Staff will record and share copies of guest lunch speaker talks if permission was given to do so. Companies and guest lunch speakers do not give consent for individual recordings, only for Epicodus to record and distribute video recordings that meet their standards.
Be forgiving when technical difficulties come up. Working remotely comes with a unique set of challenges. We all have different computer setups and configurations. While being a good pair means coming to class with your computer ready to code, often we don't know if there are issues until we start coding. Sometimes really great tools, like VS Code Live Share and Discord, seem to act finicky some days. You may find that some days in class feel like you've spent more time troubleshooting these issues for you or your pair than actually coding.
This is okay.
Part of your journey as a developer at Epicodus is learning to be comfortable working through technical challenges. These kinds of issues are common in any development environment. As the tech community has shifted more to working remotely, your time troubleshooting these issues now will only better prepare you later. Companies will likely ask you about your experience working remotely during interviews. Recalling positively the challenges you've had at Epicodus and what you've learned from those challenges will make you stand out.