During in-person classes at Epicodus, we practice pair programming where two people use the same computer at the same time. Even for remote classes, students will practice pair programming. Even though each student has their own machine, they will virtually share a screen, code editor, and so on.
One person drives, controlling the keyboard and mouse, and the other person watches and talks. Throughout the day, pairs switch off so that each person gets to drive frequently. There are several reasons why pair programming can be more effective than soloing:
From past classes, we've seen that teamwork and communication skills are actually more important than coding skills when it comes to applying for jobs. So use pairing as a way to build your skills in these areas!
Even though pairing has many advantages, it can be frustrating at times. You'll often be working with someone who is either more or less experienced than you. You'll often feel like you're slowing down your pair or they're slowing you down. You might want to explore how something works while your pair wants to focus on actually finishing the project at hand. You might run into a difficult bug and you'll have different ideas about the right way to try to fix it.
Every day at Epicodus before you start programming, we'll ask you and your pair to check in with each other. Here are some of the things you should discuss:
Do you take a lot of notes, talk things through before starting, or explore lots of tangents? Finding out about your pair's style and discussing what to do if you have different approaches or priorities can help you avoid conflicts later.
Do you want to have a signal or a predetermined time to change drivers? Some people have a tendency to dominate driving while others have a tendency to hang back and watch. It's best to try to balance these tendencies out so both pairs have equal opportunities to drive.
Are there any particular challenges you expect for the day, or any goals you'd like to work towards? For instance, identifying which content you each found most challenging can help you plan the day. Similarly, determining goals (and not being too hard on yourself if you don't meet them) can help your productivity.
We'll also ask you and your pair to check in with each other again after lunch. That is a good time to communicate what is and isn't working. For instance, you might discuss whether the driving between pairs is balanced enough, any blocks in communication that have come up, or any new challenges or goals to address as your project and understand of content changes.
If you do end up in a situation where you're feeling frustrated or uncomfortable, your pair is probably feeling that way, too. Take a deep breath, take a break if you need to, and then talk it through with them. It's tough, but it's better than suffering through the day. Ask a teacher if you need help having that conversation. Remember that everybody will have difficult pairs, especially at first. But it's worth it when you find people who you work really well with. If you do find that a situation is hostile or you are uncomfortable having that conversation, please reach out to a teacher immediately for further guidance. In rare cases, it might be necessary to find another pair or solo for the rest of the day.
In general, you'll be switching pairs everyday. Finding pairs can be tricky and awkward, especially at first. It's fine to just jump in, introduce yourself, and then get started. Over time, you'll find others that you pair well with. Ideally, you'll want to pair with others who are relatively close to your level of understanding. If you always "pair down", you won't push your limits. If you always "pair up", you'll find that even if you think you understand a concept, you won't be able to implement it yourself.
Note that the terms "pairing up" and "pairing down" simply compare where each person is at in terms of knowledge and understanding of that day's concepts. In no way should this be used to evaluate a person's intelligence or capacity to become a developer. People have varying levels of previous experience. Some people already have knowledge of coding concepts while others may have worked at technical jobs that allowed them to develop their problem-solving capacity in interesting ways. Some people struggle with one concept but quickly grasp another. Others may have had to deal with structural disadvantages in the past, such as not growing up with a computer in the house, being discouraged from pursuing technical careers, or dealing with other life issues. Still others may be dealing with personal issues in the moment - whether a lack of sleep the night before or other long-term stresses.
Please refrain from making value judgments about your peers (or yourself) based on your perceived difference in skill sets. It's all too common for students to come to teachers sure they are falling behind or struggling more than others - only to learn from their teacher that almost everyone else is saying the same thing!
To make finding pairs easier, your Epicenter account provides suggestions of people to pair with based on your most recent code reviews, or randomly for the first week of class. If you have a few days in a row where your pairs haven't been well-matched, talk with a teacher and they can help you find a good pair for the next day.