DEV Community

Cover image for Navigating the World of Pair Programming
Accreditly
Accreditly

Posted on

Navigating the World of Pair Programming

Pair programming, a key practice in agile development methodologies, has gained considerable attention for its potential to improve code quality, foster knowledge sharing, and enhance team collaboration. However, like any technique, it comes with its own set of pros and cons. In this post, we'll dive deep into what pair programming is, how it works, its benefits, drawbacks, and best practices to make it work for your team.

As part of our series on programming productivity, we've been discussing everything you need to know about pair programming, so if you're looking for a deep dive then definitely start there.

This article is aimed at developers who have probably heard of pair programming but never tried it, or those who have never heard of it at all.

Let's jump in.

What is Pair Programming?

Pair programming is a collaborative programming technique where two developers work together at one workstation. One, the "driver," writes the code while the other, the "navigator," reviews each line of code as it is typed in. The two programmers switch roles frequently, fostering a more collaborative approach to problem-solving and code creation.

In more recent years, and especially with the pandemic, pair programming has happened remotely as well as in person. There are various plug-ins available for the likes of VS Code that make this easy, but anything that allows you to share a screen will do the job, although a specialised tool is better (you'll often want to draw on the screen, or take keyboard control).

Microsoft VS Code users can start with Live Share.

How Does Pair Programming Work?

In a typical pair programming session, the "driver" and "navigator" work closely together. The driver is in control of the keyboard and actively implements the code or solves the problem at hand. The navigator, on the other hand, is responsible for reviewing the written code, spotting errors, and providing strategic direction.

One crucial aspect of pair programming is role swapping. After a set period, or after completing a specific task, the driver and navigator switch roles. This switch not only helps keep both developers engaged but also promotes knowledge sharing and mutual learning.

You should set a clear set of rules at the start of each session that you're both happy with.

Benefits/Pros of Pair Programming

Pair programming provides several benefits:

  • Improved code quality: Having two pairs of eyes on the code can result in fewer mistakes and better overall code quality. The navigator can spot errors or suggest improvements on the go, reducing the need for extensive code reviews later.
  • Knowledge sharing: Pair programming fosters knowledge sharing and mutual learning. Both developers can learn new strategies, techniques, or shortcuts from each other, improving their skills.
  • Better problem-solving: Two minds are often better than one when it comes to problem-solving. Collaborative discussions can lead to more innovative solutions and faster problem resolution.
  • Reduced risk of blockage: When working alone, a complex problem can halt progress. In pair programming, the combined knowledge and perspective can help overcome these obstacles more quickly.
  • Improved communication: Pair programming can enhance team communication and rapport, leading to a more cohesive and productive team.

Cons of Pair Programming

Despite its benefits, pair programming is not without its drawbacks:

  • Higher resource requirements: Pair programming means two developers are working on the same task, which could potentially be seen as doubling the human resources required. Take this with a pinch of salt - often the motivation of working with someone else has a big productivity bonus. Experienced engineering managers recognise this.
  • Personality clashes: Not everyone works well together. Personality clashes or differences in work styles can make pair programming less effective or even counterproductive.
  • Increased pressure: Some developers may feel uncomfortable or pressured when coding with someone else watching, leading to stress or decreased productivity. Some developers just don't work well in these environments and it shouldn't be forced.
  • Scheduling challenges: Coordinating schedules for pair programming can be challenging, especially for remote teams across different time zones or smaller teams with constrained resources.

Best Practices for Effective Pair Programming

To maximize the benefits of pair programming and mitigate its drawbacks, consider the following best practices:

Switch roles regularly

Regular role swapping can keep both developers engaged, foster mutual learning, and prevent one person from dominating the process.

Pair with the right programmer

Pairing with the right programmer helps here. You should try and pair with a programmer of similar ability unless the goal is mentorship.

One often over-looked point here is that the programmer you pair with should have a similar level of project knowledge as you. If you're in a larger team covering many projects then there's likely going to be differences in knowledge of the inner workings of a project as well as general development knowledge.

If the goal is to share project knowledge then it's OK to have developers working together with different levels of project knowledge, but if this isn't clearly communicated then it can lead to frustration.

Choose pairs wisely

On from the above, it's not just the project knowledge and development skillset to be considered. Also consider each developer's personality, work style, and skill level when forming pairs.

Sometimes, pairing a less experienced developer with a more experienced one can be a great learning opportunity. Just communicate the roles clearly.

Take regular and scheduled breaks

Pair programming is an intensive task. You should both take regular breaks and do your best to schedule them.

Seasoned pair programmers can go for much longer without needing a break, but those new to it can quickly get overwhelmed so understand the limitations of both yourself and your partner.

Ensure clear communication

Encourage open and respectful communication between the pair. Both members should feel comfortable giving and receiving feedback throughout the process.

After the session try to give constructive feedback to your partner. Having time set aside at the end of the session for this feedback helps.

Plan before you begin

You shouldn't just jump into a pair programming session cold, especially if you or your partner are new to it. Before you start you should have the following information clearly communicated to both parties:

  1. Who is the driver and who is the navigator for the first session.
  2. What is a session/when do you switch roles? Is it time-based (every 30 minutes, for example), or is it task-based?
  3. Like a good meeting, a good pair programming session should have a clear agenda. What do you intend on completing in the session? If you're working on a task-based role swap system then it's a good idea to plot this out before you begin. Experienced pair programmers are able to do this more ad-hoc, but more novice pair programmers should do more prep so they can focus more on the programming and less on the running of the session.
  4. What are your strengths and weaknesses? Be open and honest at the start of the session; tell your partner what you're good at and what you're not good at. Great at database queries, but struggle a little with complex loops or logic? Make sure you are playing to each other's strengths.
  5. Share your project knowledge. If you've worked on this project for hundreds of hours already you'll likely know the decisions that have been made all over the app, whereas if you're new to the project you may need more context. Being open and honest here makes it easy for your partner to know what to expect.

Be punctual and prepared

Pair programming sessions are usually planned way in advance. It's common courtesy to turn up prepared and ready to go:

  • Don't turn up late.
  • Don't turn up without a coffee/tea/water.
  • Have the project pulled and set up for local development.
  • Familiarise yourself with the project as best as you can.
  • Have a pen and paper ready for note taking.

Summing up

Pair programming, when implemented correctly, can be a powerful tool for improving code quality, fostering knowledge sharing, and enhancing team collaboration. However, it's not a one-size-fits-all solution. Understanding its pros and cons and employing best practices can help you determine how to best incorporate pair programming into your team's workflow.

If you're interested in learning more then check out our article: Everything you need to know about pair programming

Have you tried pair programming? Share your experiences, tips, and insights in the comments below!

Top comments (4)

Collapse
 
ant_f_dev profile image
Anthony Fung

Great overview of pair programming. For anyone using Visual Studio, the latest version (and possibly 2019 too) also has Live Share built in, which is really good for remote team working.

Two points based on my experience with pair programming:

  • When working at the same workstation, having two keyboards plugged in can improve the overall experience as there's less interruption if the navigator wants to make a suggestion/edit.

  • I used to really dislike people watching me live-code. Pair programming can help to alleviate this as you learn to work with someone in real time.

Collapse
 
accreditly profile image
Accreditly

The 2 keyboard point is great - I've never done that. Will give it a try!

Collapse
 
ant_f_dev profile image
Anthony Fung

Please do let us know if you find it helps - it certainly made things smoother in my experience.

Collapse
 
alvarolorentedev profile image
Alvaro • Edited

Awesome article. Thanks for sharing.
I will like to add that one of the other benefits to projects itself:

  • Less silos: of tbere is pair programming and rotarion happend everyone ends up improving their knowledge of the product.
  • More ownership: if there are less silos we can as a team own better the entire solution.
  • Better flow/reduce waste: at the end pair programming is a peer review methodology. Its sync and wastless, the changes are done on the fly, not like PRs (widely overused), that nornally require a lot of rework at the end of the flow generating a lot of waste.