Pair Programming 101: A Guide for Aspiring Software Engineers

Pair programming is when two software engineers create code together. It’s a powerful Agile development technique for software engineering teams and is a core part of my teaching approach at Code Platoon While many of my students are hesitant to start pair programming, this collaborative approach improves the quality of their coding and fosters stronger teamwork, creativity, and professional growth in every cohort. I know it can do the same for you, too.

3 Reasons to Learn Pair Programming

Adjusting from solo programming to pair programming is like eating spicy food. The first time you try it, you might not like it, but the more you experience it, the more you’ll get used to it and may prefer it. 

Here are three reasons to learn pair programming:

1. Produce Higher Quality Code: On average, pair programmers spend about 15% more time solving a problem than individual developers, but their code will have 15% fewer defects than if they had worked individually. This may not sound like a lot, but it’s a massive improvement.
2. Create Higher Satisfaction: Pair programming allows you to collaborate on interesting and challenging topics for your project. In an online survey of programmers, 96% stated they enjoyed working within pairs more than working alone. There’s nothing better than tackling a good problem together and working on a gratifying solution!
3. Learn How to Work Together: Although you may prefer working alone, many software engineers work in teams, so knowing how to program together is essential for your professional development.

Ideally, your partner will be a more experienced developer who’ll share new tips and tricks. But even if you’re programming with someone less skilled, you’ll still be exposed to different problem-solving approaches.

How to Pair Program

First, decide how to meet with your partner and share your code. Zoom and Visual Studio Live Share are both friendly tools that I recommend. Next, create the requirements for your project and decide which role you’ll each take:

1. Driver: If you’re the Driver, you interpret the ideas for your project into code. You’ll sit at the computer or share your screen and start programming. As you code, you’ll listen to feedback from the Navigator and continuously verbalize your thoughts, concerns, and any questions you have as you’re working. 
2. Navigator: As the Navigator, you review the code as the driver writes it to ensure it meets your project’s requirements. Don’t just provide answers to the Driver or try to lead the Driver into solving a problem exactly as you would. Instead, suggest how the Driver could steer their code to meet the requirements.

Once you establish roles, you can move on to problem-solving and writing code. Pair programming shouldn’t be silent or divide-and-conquer; you and your partner should continuously communicate about the vision for your project.

Generally, don’t aim to pair program for more than an hour at a time. Working for longer than that quickly becomes draining. Take a break if the project needs more time; you can always meet again for another session.

At the end of this process, you and your partner should leave with higher confidence in your code. Before departing, you and your partner should also provide constructive feedback to each other and ask any questions you may have from the process. And that’s pair programming in a nutshell!

Francisco is the Lead Full-stack Software Engineering Instructor at Code Platoon. He served in the United States Marine Corps for eight years as an Infantry Mortarman and an Infantry Combat Instructor. Francisco graduated from Code Platoon’s Full-stack Software Engineering: Immersive Romeo Platoon and is pursuing a bachelor’s degree in Computer Science. He enjoys running with his dog, hiking with his family, and reading in his spare time.