Pair programming is the practice of working on a single problem with a peer on one shared workspace. Some companies use pair programming for 100% of their work; others never use it; others use it for specific occasions, such as when onboarding new developers. The goal of pair programming is to catch errors more quickly and write higher-quality code through collaboration.
Pairing will be uncomfortable when you first try it. It's a skill in and of itself that requires practice and feedback to master. Pairing has been shown to improve performance on technical skills in programming courses, and lets your coursework more closely mirror a job environment with challenges that are both technical and interpersonal. It also helps keep you on-task and motivated.
When you're pairing, you'll find yourself working with people who think differently, and people with higher and lower skill levels. Pairing will help you learn to work with people who have different personalities, communication styles, and will push you to become stronger at articulating programming concepts (which will become crucial in interviews).
In pair programming, there are two distinct roles: the driver and the navigator. Both have access to a keyboard, but the driver does most of the typing. Pairs should discuss a problem and agree on a rough solution, and then the driver is responsible for implementing it.
The navigator is responsible for keeping the larger picture in mind and guiding the driver in the right direction. The navigator also watches for syntax errors, thinks about solutions to the problems the pair is solving, and researches questions in the background. The navigator generally should not dictate code word-by-word, but instead should provide general directions that the driver then implements.
Take 5-10 minutes upfront to discuss expectations for the session. First, introduce yourself. Tell your pair where you're from, how long you've been working in the course, and share something you're anxious about in this career transition. Next, ask each other about your experience with the topic, and any personal preferences on how to learn. If you're already comfortable with each other, this time should be spent laying out the plan for this session.
Aim to switch off driving and navigating about every 30 minutes. Switching gives you a chance to take a step back to consider what you've done and what you'll do next, and makes sure both members of a pair understand what you're building. When you switch, the driver should push his or her work to GitHub and the navigator should pull down that work. The new driver should first review what was done and discuss the plan for the next step.
Remember that one of the most valuable aspects of this program is the steady flow of feedback you get from your peer. Take a few minutes to give your pair feedback on their communication, and if appropriate, provide suggestions for how they can improve their programming. Don't forget to provide positive feedback on what your pair did well! It's important to use this time to reflect and address any feedback to make future sessions more efficient.
Be patient with your pair if one is having an easier time understanding the day's work. Don't feel too embarrassed if your pair takes on the role of teacher for the day, and if you have experience with a topic, don't work ahead without your pair understanding what you're doing. At no point should either student feel as though they're not contributing to the project or learning something new. One benefit of pairing is being able to vocalize your understanding, and help each other identify weaknesses in that understanding.
When giving feedback, pick your words with care and make sure to say what you actually mean. When receiving feedback, assume the best of your pair. He or she almost certainly intends to help you be productive and improve your skills, though every suggestion may not come out quite right. If you feel your pair isn't being sensitive to your needs – for example by driving for an entire day – speak up! Your pair is learning this new skill, too. Make sure you bring up your concerns with specific feedback.
As you work, explain what you're implementing, including why you are making a decision.
We'll primarily use Thinkful's video chat for pair programming. Though this will make it easy to share and work on code, this doesn't eliminate the barrier to remote work. Working remotely makes it harder to understand someone, particularly if there's any subtlety to something they're expressing. Aim to over-communicate and be incredibly explicit about what you're doing and how you're feeling; when you're sitting next to someone, you may know when they're starting to get tired, but that's much harder to intuit remotely.
Make sure you have headphones that you're comfortable wearing for the whole session. Headphones will reduce audio feedback and make it easier to hear each other.
When you're pair programming, the easiest way to work is with Github. The first driver should create a new repository when you begin. Then, each time you switch off between driving and navigating, the current driver will commit the changes with a good message, then push those changes to GitHub. The new driver will then clone (if it's the first time) or pull (git pull origin master) the changes down, so you'll be able to continue working. Each of you should have write access to the repo, so the creator should go into the settings, and add the other pair as a contriubitor.