3 min read

Pair Programming

What is pair programming?

Pair programming is the practice of having two developers simultaneously working on the same task. There is a driver and a navigator, who can swap roles at will. The driver is writing the code and the navigator is helping solve problems and suggesting ideas.

Advantages of pair programming

Efficiency

  • Having two people work on one task is not necessarily half as fast, because unlike data entry, you are not limited by how fast you can type, but more so how fast you can solve problems and come up with solutions

Team cohesion

  • Get to know each other through working together
  • More social

Code quality

  • It's like a live code review - constant constructive feedback. This also results in increased confidence in a decision on which implementation/solution to use along with lower likelihood of bugs
  • Less likely to forget things like running tests

Knowledge Sharing

  • Leveraging the knowledge of both developers and if one developer has specific knowledge, this will be shared with the other developer working on the task, preventing knowledge silos

How to do it well

It is important to rotate pairs often, this helps to share knowledge with as many members of the team as possible. If one pair learns really useful information during a task, by rotating mid task they are able to infect the rest of the team with that knowledge.

The downside of constantly swapping pairs is the context switching. It does not make a lot of sense to have a pair get started on a task, spend the time getting their bearings and understanding of a problem they need to solve, then going in blind on a new task while another new pair comes in having to do that work again.

My idea is for each pair, you have a 'task owner' who stays on that task through the lifecycle of the task and is responsible for its delivery. This also can serve as a way to resolve debates in implementation, being a designated decision maker. This way we can mitigate the downside of context switching while improving the knowledge sharing aspect of switching pairs.

As a driver, it is very helpful to explain what you are doing. This way, the navigator is on the same page as you.

Pair Programming Techniques

Ping Pong Pairing: One developer starts as a driver and writes the failing test, the pair then switches role and the new driver writes the solution to the test and then the next failing test, where original takes over and does the same. Below is an image example.

  • This enforces TDD (Test Driven Development).
  • Navigator does not get bored watching
  • Collective ownership of code
  • Shared decision making

When Not to Pair

Trivial tasks

  • No benefit from having extra help and the navigator gets bored watching it happen

Spiking code

  • Just trying things to see if it works, code that won't go into production
  • A better approach would be, once you can see that it works, redo it properly in a pair

The significant advantage of pair programming for junior developers

It is a significant advantage to use pair programming for your juniors. From experience I have seen that a junior working alone will be assigned the simple tasks such as simple bug fixes or updating images. This can result in some useful learning, but if you are pairing a more senior team member with a junior, the senior can lead the implementation of a much more complex task and the junior will learn significantly more in a much shorter amount of time.

The junior developer has an increased morale and confidence in their ability as they are delivering many interesting tasks in a good amount of time, rather than scraping together simple solutions while watching their more experienced team mates solve much more complex problems easily, which can be demoralising.

The other big advantage is that a junior, especially in the early days in a new role, will require quite a bit of support anyway. They may get stuck on a problem, they may need help to follow the correct git process specific to that company. By pairing the whole way, the junior won't waste time trying to figure these things out.

It is common for a junior developer to, even on a simple task, spend a lot of time on an inferior solution, only for it to be later corrected by a senior which could be as late as the code review stage. I remember my first ever task was to implement validation on an input form and my idea was to write my own convoluted string manipulation, completely unaware of regex. My tech lead came over to check in on me after half the day had passed of me trying to implement this solution and suggested that I use regex. I was then able to solve it within minutes. If we had paired, we would have solved this very quickly and I would have learned that lesson, then be ready for the next task to learn my next lesson.

There is still value in the junior developer doing some solo tasks mixed in, as it exercises the muscle of figuring out how to solve issues themselves, but this should not be the norm.