{"id":167,"date":"2019-05-16T00:00:58","date_gmt":"2019-05-15T23:00:58","guid":{"rendered":"https:\/\/blog.drovio.com\/?p=167"},"modified":"2021-11-25T17:50:19","modified_gmt":"2021-11-25T16:50:19","slug":"reasons-for-pair-programming","status":"publish","type":"post","link":"https:\/\/www.drovio.com\/blog\/reasons-for-pair-programming\/","title":{"rendered":"Reasons for Pair Programming"},"content":{"rendered":"\n

What most effective teams have in common is certainly their ability to work together. When it comes to software development, one way to work together is pair programming.<\/p>\n\n\n\n

Pair programming is a technique where two developers sit at the same desk and code together. The purpose is to spread knowledge over the team, share good practices and sometimes overcome technical challenges by combining two people experiences to solve a problem. At any time, one developer is coding while the other one reviews each line as they are typed and thinks ahead. They must engage with the task to perform for this exercice to be beneficial. Thus, no place for procrastination.<\/p>\n\n\n\n

From the point of view of a manager, two developers working on a single task may appear like a waste of resources. However, studies have shown that for a 15% longer development time, pair programming improves code quality, reduces massive show-stopper bugs and enhances team communications (see \u201cThe Costs And Benefits of Pair Programming\u201d: https:\/\/collaboration.csc.ncsu.edu\/laurie\/Papers\/XPSardinia.PDF<\/a>).<\/p>\n\n\n\n

Let\u2019s see when to pair and how to do it effectively.<\/p>\n\n\n\n

Learn<\/strong><\/h2>\n\n\n\n

Even though the ultimate goal is to produce a fully working piece of code, pair programming can be employed for various reasons. Generally, it depends on the skill level of the participants.<\/p>\n\n\n\n

Onboard a junior developer<\/h3>\n\n\n\n

The most common usage is a junior programmer pairing with a senior one. The former types while the latter instructs on what to do or help the junior figure it out without giving the solution beforehand. In this case, pair programming is used as a learning and on-boarding tool. <\/p>\n\n\n\n

Roles are not exchanged at first. Junior programmers can\u2019t learn by only watching someone else type lines of code they might not even understand. Either because they don\u2019t know the code base yet or because they\u2019re lacking experience. They have to experiment a bit their ideas and make their own mistakes to learn.<\/p>\n\n\n\n

Pair programming with an annoyed senior developer<\/figcaption><\/figure>\n\n\n\n

Thus, senior devs have to resist the urge to always take over the keyboard control and even show any sign of irritation. Patience is the key here. Sure you would have done the task in a minute, but would that serve any purpose? You don\u2019t want juniors to be discouraged and leave the team. Instead, senior devs should progressively bring juniors to the path that lead to success. <\/p>\n\n\n\n

To make this happen, the junior dev speaks their mind aloud as they type. When the senior dev disagrees, they let them reach a dead end then explain why it was not working. Another approach is to ask questions as the junior dev tries to describe what they\u2019re going to do. They\u2019ll inevitably doubt about the proposed solution. This way, they can understand by themselves it would not work and will actually learn. It requires a lot of patience and sessions should be definitely kept short, the exercice being so exhausting for both parties. At the end though, junior devs will be way more engaged and motivated.<\/p>\n\n\n\n

Who's benefiting?<\/h3>\n\n\n\n

The junior dev, mostly. Yet we all have different visions when it comes to problem solving and juniors can bring a breath of fresh air to a project you should not underestimate. Also, senior devs who\u2019ve been part of the team for a long time well often share the same point of view on a code base and how things should generally be done. A junior dev, however, usually ask questions that force the veterans to explain what some portions of code actually do. This helps to detect design flaws early on that you wouldn\u2019t have suspected at all. You onboard a new team member and at the same time review what has been done before, making sure it\u2019s understandable and that it won\u2019t all fall apart someday. Win-win.<\/p>\n\n\n\n

Build up self-confidence<\/strong><\/h2>\n\n\n\n

Two juniors pairing together is generally considered a bad combination. They can\u2019t rely on an experienced developer to help them sort their minds. On a complex story, when dealing with agile projects, they\u2019ll lose time investigating each dead end. That generally leads to frustration and failure, also potentially increasing project risk.<\/p>\n\n\n\n

A senior dev should approve the stories they pick, generally simple stories. It can work if the team is ready to accept errors and if the juniors already had prior pair programming experiences with a senior dev. They\u2019ll be able to share with each other what they\u2019ve learnt from their past pairing experience. <\/p>\n\n\n\n

Also, there are always trade-offs to be made when dealing with development. When they have no senior dev around at disposal, junior devs have to take their own decisions. Something they could be reluctant to do when pairing with a senior, too worried to seem somehow dumb. Taking decisions is an essential part of the learning process when coding. It allows devs to build up their self-confidence.<\/p>\n\n\n\n

Pair programming is a good practice to grow as a cohesive dev team. You want juniors to be more effective and expect someday they\u2019ll be able to handle stories by their own, without systematically requiring you to fix everything afterwards. For this to happen, they first need to feel they are key elements of the project and team.<\/p>\n\n\n\n

Share the knowledge<\/strong><\/h2>\n\n\n\n

The last scenario I\u2019ve not tackled yet is two senior devs pairing together. Although a senior programmer might be able to handle any story of a project, there are a few cases where pair programming can help: learn a new framework together, resolve bugs implying multiple code portions written by each parties or increase the bus factor.<\/p>\n\n\n\n

Bus factor refers to the number of people in a team that can put a project in trouble if they disappear (literally by being hit by a bus but more seriously for vacation, illness or leave). Having a good bus factor value ensures the project will eventually come to an end. The rest of the team can easily take over the work done without being lost or having to restart from ground zero.<\/p>\n\n\n\n

Bus factor experience during the last Sprint<\/figcaption><\/figure>\n\n\n\n

Pair programming helps to spread knowledge over the team and allows to increase the bus factor value. People involved on a project are no longer isolated on specific corners of the project and code duplication is avoided.<\/p>\n\n\n\n

We often pair at USE Together just for the sake of increasing our bus factor. As developers, we have our own preferences when it comes to technologies, programming languages, frameworks. Pairing allows us to move out of our comfort zones, understand quickly how some piece of code is articulated and get ready to take it over when people are on vacation or simply working on other urgent stuffs.<\/p>\n\n\n\n

Reduce code defects<\/strong><\/h2>\n\n\n\n

There are numerous flaws we can potentially write when coding solo. We sometimes lack that step back that would have permitted us to quickly realize something will not really work as intended. When implementing a solution, developers have most of the time different approaches based on their experience. Two minds combined will help reducing massive show-stopper bugs.<\/p>\n\n\n\n

Improve code quality<\/strong><\/h2>\n\n\n\n

Pair programming allows to share consistent coding practices between team members. When you expose some new way to arrange the project\u2019s code during a meeting, people might not be as receptive as you thought they were. Pairing with them on a task that would, at some point, involve following your good practices will help them remember and understand the why.<\/p>\n\n\n\n

Pair programming techniques<\/strong><\/h2>\n\n\n\n

Multiple techniques can be used to pair program. At any time, there are always one developer typing and one observing.<\/p>\n\n\n\n

Driver\/Navigator<\/h4>\n\n\n\n

A classic one. The driver takes the keyboard and mouse control, writes code, navigates between files and mainly focuses on the current step to be done. The navigator, on the other hand, is responsible for reviewing each line of code being written and thinks more about the big picture: are we on the right track? Will that cause some bugs to emerge? What\u2019s the next step? Driver and navigator often switch roles every 5, 20 minutes or each hour. It mostly depends on the pair but that should happen. Otherwise, the driver will feel exhausted quickly and the navigator will be bored and tempted to procrastinate.<\/p>\n\n\n\n