At Epicodus, we practice pair programming where two people use the same computer at the same time. Students in our remote classes will also practice pair programming. Even though each student has their own machine, they will virtually share a screen, the same code editor, and so on.
In pair programming, one person drives, controlling the keyboard and mouse, and the other person watches and talks. Throughout the class, pairs switch off so that each person gets to drive frequently. There are several reasons why pair programming can be more effective than soloing:
- Programming is less about writing massive amounts of code and more about solving difficult problems. Two heads are often better than one when coming up with solutions.
- Usually, each person in a pair will have different knowledge and different strengths. Pairing lets you learn from each other.
- When you work alone, you're often tempted to take shortcuts that will come back to haunt you. For example, you might not adequately test your code to make sure it works. When pairing, you can hold each other accountable to writing high-quality code.
- When you watch somebody else code, it's easier for you to see their mistakes and catch their bugs. The reverse is also true — they can help you spot mistakes you aren't seeing!
- You don't check your email, social networks, news, text messages, and so on when you're pairing. As a result, you're much more productive.
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 class session 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 class session, or any goals you'd like to work towards? For instance, identifying which content you each found most challenging can help you plan your time. 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 understanding 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 class. 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 class.
In general, you'll be switching pairs every class session. Finding pairs can be awkward, especially at first. It's fine to just jump in, introduce yourself, and then get started. To make finding pairs easier, every course section we assign you to a development team (dev team) of about eight students to work and check in with. Every class session, you'll find a new pair from your dev team to work with. We'll learn more about dev teams in a later lesson.
You should expect that you will regularly “pair up” and “pair down”. Some days you'll “pair up" with somebody who understands the concepts better than you. Some days you'll “pair down" with someone who understands the concepts less than you. Over time, you'll find others that you pair well with. You might pair well because you share learning styles, move at a similar pace, or have a similar level of understanding of concepts.
The terms "pairing up" and "pairing down" simply compare where each person is at in terms of knowledge and understanding of that class session'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!
It's important to work with a wide variety of people, including people at your same 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. If you have a few class sessions in a row where your pairs haven't been well-matched, talk with a teacher. Overall, you should expect that you will regularly pair up and pair down throughout the program.
When you are pairing down, take the opportunity to really solidify the concepts and technical terminology at hand. You can offer to share your strategies for practice and understanding of concepts. If your pair asks for your insight, you can try to teach the concepts that your pair may be struggling with. Teaching is the best way to verify how well you know a concept. Overall, make sure that you check in with your pair regularly to ensure that you are on the same page when you are driving, and take initiative to switch who is driving regularly. When you are not driving, always give your pair space to work out their ideas. Engage with your pair by asking questions about their approach to problem solving.
When you are pairing up, make sure that you are regularly checking in with your pair about what you do and do not understand. Questions are always good! Don't ever feel badly about yourself for not knowing something that someone else does. Throughout your entire career, there will always be someone else who knows more than you, so take the opportunity to learn from them. Likewise, though you may know less about coding than your pair, that doesn't mean that you don't have good ideas as far as problem solving. Share your ideas freely and ask your pair questions. Make sure that you and your pair are switching who's driving regularly — while you can learn a lot from watching someone else code, you also need to take time to practice so you are adequately prepared for your independent projects. When you are driving, be sure to take the time to develop and discuss your ideas and problem solving steps for the task at hand.
It's extremely common for students to not understand something the first time they read about it. Likewise, it's common to need time, practice, and repetition to really understand concepts. Students often revisit concepts later and work on certain concepts over a few course sections. So, if you don't understand something yet, you will soon!
Stay positive, have fun, and take breaks! Remember, being a developer is not about learning a fixed set of skills that you can apply for the rest of your career — the languages, tools, and approaches you'll learn here are much less important than the general skill of solving problems.