Pair Programming

You’ll often hear about developers (including both of us) who regularly use pair programming. The practice of pair programming can be very helpful for sharing knowledge across the team, working through a difficult chunk of code, or simply showing how your team approaches their daily workflow (especially when working with a new hire). Pair programming also helps team members get to know each other (and each other’s thought processes), which is very important in our current COVID age where people are working remotely. It can be hard to convince management and other developers to allow pair programming. Your typical corporate bean counter will see the practice as simply doubling the cost of the same piece of work. Project managers will often view the practice as something that jeopardizes project timelines for dubious benefit. Other developers might balk at the idea as well, both because they are self-conscious about the way they write code and because many find it boring. Furthermore, to nearly everyone involved, it sounds like yet another meeting that will chew up part of a day (most meetings stink and most people don’t like them). Pair programming is a useful way to improve code quality, cross train team members, and on-board new developers quickly without boring training. In addition to making it easier to solve more difficult problems, it also helps with team cohesion and helps people understand how other team members think. Best of all, if done properly, it may not negatively impact your team’s throughput – it could even improve it. Episode Breakdown Basics Of Pair Programming What is it and why do it? Pair programming requires two programmers (if more, it’s called a mob) to use a single computer. One developer will work, while discussing what they are doing with the other. The second developer might also have a computer or other device and use it to take notes, look up things for the first developer, review specifications, etc. Basically, the idea is that with two developers working on a piece of code, you avoid creating knowledge silos, improve the quality of the code you are writing, and increase team cohesion by having people actually work together. Team cohesion from pair programming is often an undervalued result, but is especially important when dealing with remote and distributed teams. Even in organizations where pair programming is not common, it does often happen during onboarding a new team member. The larger practice of pair programming can be viewed as a long term extension of this onboarding practice. When to pair program? You are probably not going to want to pair program all the time, since it can be exhausting. Instead you should be more strategic about when you do it. Ideally, you will only pair program when it actually provides value. Pair programming works well when you are trying to show another developer something they haven’t seen before. It also works well when you need two people’s expertise to actually complete a task. This happens a lot when porting an old system to a new framework, or when trying to migrate data between systems. It’s also good for onboarding new developers and getting them used to your company’s processes. Pair programming is very effective when you need another developer’s help to get unstuck. When not to pair program It’s very difficult to pair program when the two developers involved don’t get along, have a major language barrier, or don’t use similar technologies to do their job (unless one of them is trying to learn the technology used by the other). When you don’t have a clean way to share a screen and to give control to the other party (some security setups make this difficult, especially when you are remote).