I want to share my experiences and observations of pair programming, that I have made pair coding at work and facilitating coding workshops such as coding dojos and coderetreats the past years.
I think it is more than just two people sitting in front of a computer and doing the work of one.
First I would like to introduce you to XP, you might be familiar with the abbreviation XP as in experience, but it also stands for eXtreme Programming (XP) and it originates from the 1990s. Kent Beck and his colleagues described pair programming in the book “Extreme programming explained”. At the time these ideas were considered extreme and pushing collaborative programming to a different level. This was in the 1990s, and now with agile method having been adopted more and more since the 2000s one might think pair programming is more widespread. A lot of XP things have been adopted and you may be familiar with concepts of collective code ownership, continuous integration, code testing, talking to the customer, but these human-centered practices have still as far as I can tell not been so widely adopted.
In the past when computer time was precious people were working together to get things done and correcting before running a program on a computer and to be sure to use its computer time effectively. In a way pairing was the usual mode of working, you can take a look at “Psychology of computer programming” by Gerald Weinberg from the 1970s, where he describes a lot of practices and collaboration patterns people used before one computer per person became the norm.
So let's not wait another 20+ years!
Let's and dive into the topic now.
In his book Kent Beck explicitly described pair programming as a practice, where two people equally share the responsibility for doing the work and getting it done.
How do they do that when there is only one keyboard?
In pair programming two people occupy distinct roles, the one is the driver and the other one is the navigator. In the sense of going on a road trip together, where the one is paying attention to immediate things and the other one checks what will come ahead. They arrive together and the fashion in how they do that, is determined by how they work and interact together.
As a driver, you will have the keyboard and your job is to write the code. As a navigator, your job is to support the driver while observing what is being written and keeping an eye on the overall context it is in. Keeping this in mind both need to communicate about what they are writing or what they deem as being important as the next step. As a driver, you keep the navigator updated about what you want to write next, this way the navigator can more easily support you. As a navigator, you keep the driver on track so that you both don't end up in a ditch. It is necessary to give feedback on the code, or quickly read some documentation so that the task gets done. Switching roles every now and then can help you to keep focus and also change the way you think about the task ahead.
Even if you try to keep all these things in mind it doesn't guarantee that you will have a great pair programming experience.
Some things can diminish your efforts in doing pair programming productively and some behaviors can enhance your and your pair's experience.
Collaborate!
Read the task and discuss what needs to be done. Plan it together and agree on what and how to do it. This can save a lot of stress and time.
Don't dominate!
Don't try to show off or cling to the keyboard all the time, this will disengage your pair partner, nobody likes to observe somebody programming alone. Instead, slow down and keep your pair partner engaged and informed about what happens next. This way the navigator can support you better and can give feedback while being in the loop with you.
As a navigator don't tell the driver constantly what to do, this isn't dictation, and the other one is not your scribe. Instead, communicate about what you would like to do next or differently and maybe switch roles.
Be constructive!
Don't blame your pair partner or the code you end up working with, it is not productive and probably it is your own code you are blaming. Give directions or ideas on how to improve things and demonstrate how to do it better. That way you and your pair partner can learn something together and also have a sense of achievement in having left the place better than you found it.
Turn off notifications!
In most cases it is not beneficial to work if there are too many distractions or when one is preoccupied with something else. Everything that is not focused on the task ahead should be avoided such as, reading emails and chat messages that can be done later. Turn off notifications, also on your phone.
Celebrate!
If you get a test green or some things finally fall into place, celebrate and congratulate each other for this achievement. Every little step is part of the whole and it is worth acknowledging its positive impact.
Take breaks!
There is always some things that cannot wait, so take a break or schedule breaks before hand and make them explicit and long enough so that you can use them to defocus from work. When you come back to the task, you'll have a fresh view and relaxed mind and will be able to focus more effectively than if you had paired and sat there for hours.
When you find yourself not being able to concentrate, both of you take a break and come back together and continue working.
Switch roles regularly!
Breaks are a great way to initiate a switch in roles, there are many ways to do it, e.g. writing a new failing test and the other needs to implement it to make it green. It supports in getting a different perspective to the task and to the work when you switch the roles and have to focus on different things.
With these behaviors in mind I am certain you will get the benefits you are looking for.
Faster feedback and getting unstuck faster
You have your colleague at your side to check the code and to support you when you are stuck and vice versa. You can measure cycle time of tickets that you did while pairing, it probably doesn't need a code review with the PR, since two people have worked on it and checked if the design is up to the teams standard.
Fewer defects.
Bugs found in production would be a thing that can decrease since 2 people thought about edge cases and other problems while having the context of the work item in mind. A code review probably won't catch these since the reviewer does not have the full context in mind. It would need a deeper code review that goes beyond "lgtm" and "+1".
Less knowledge and skill silos
You are actively working together and sharing how you would like to solve a problem. Talking about solutions and the domain will certainly help you and your pair partner to not be the only one who knows what was done and why and how it got in the new state.
Staying focused
Two people are usually less likely to be interrupted, especially in an office setting. In a remote setting you can benefit from having turned off notifications while pairing.
Pair programming is not a one size fits all practice since everyone is different. To get a better experience each time discuss what was good and what can be improved for the next time.
Happy pair programming!
Top comments (1)
that pair programming is the practice of two programmers working together on the same task on the same computer. Usually, one of them is the driver (or a pilot) and the other is a navigator. جلب الحبيب بالدعاء