Why Pair
On teams, developers want to get more done. Less experienced developers need to learn from the more experienced developers. The organization needs to be structured to avoid needing n squared communication channels.
"Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team’s practices. Pairing" - Kent Beck
Pairing allows developers to ...
- Produce better solutions
- Share knowledge and context on the fly
- Mutual learning and skill development
Definitions
Pair programming is the practice of pairing up to work on development tasks. Most people think of two developers sitting at the same machine, sharing a keyboard. With the increasing popularity of remote work, it is now possible to pair program while thousands of miles apart.
Driver
Fingers on keys; typing code.
Navigator
The developer that indicates what should be typed; decides the direction to go.
Most forms of pairing involve taking turns typing. One person types (the driver) while the other person thinks through what is being done, and what needs to be done next (the navigator). These roles are frequently swapped.
Both members must verbalize their thought processes when pairing to be effective. Successful pair programming relies on successful communication as much as programming skills. The premise of pair programming is that when working on a complex task, "two heads are better than one."
Patterns
Strong Technique
The Strong Technique is an approach where the driver does nothing that the navigator did not direct.
For the driver to provide an idea, they must handover the system to the partner and then carry out the control from the navigator position. This approach completely engages the observer.
Traditional Technique
Traditionally, pair programming has been popularized through the driver-navigator technique. Ideally both the team members should switch roles at times for better results.
With this style of pair programming, the navigator often loses interest. Possibly because the person in charge of typing is not communicating well, or perhaps the navigator does not want to bother him. Many times the driver puts forth, "just a minute, I’ve got an idea ..." and continues working; the navigator is left behind.
Ping Pong (TDD Swapping) Technique
Using this pattern, one of the developers writes the test that fails and the other developer writes the code to get the test to pass. Then, the pattern is repeated.
The biggest challenge with this pattern is finding time refactor the code and do testing. In fact, more time is often spend on the test refactoring than the coding. Implementing a feature can be complicated and it will make testing complex too. Developers must also pay attention to the simplicity of the code so that it can be effortlessly maintained in the long run. This idea also applies to testing.
Leap-Frog Technique
This pattern can be best described by looking at two developers in different time-zones. One is working on front-end code, the other on back-end code. They work toward a common feature, taking the development lead ... moving the code forward.
Rubber Duck Technique (Grab a Buddy)
Here, the pairing is often two developers at similar levels. One, working on some code, is stuck and in need of an "extra pair of eyes." Often, someone not as "deep in the weeds" will be able to see what the original developer missed.
Mob Technique
The Mob Technique can be used well with code abstractions to develop a conceptual implementation.
This technique allows several developers to contribute at one time. Many are referencing code and finding implementation patterns for use or validation, while one or two individuals are writing code.
This technique could also be used when in a teaching (or mentoring) role to give the group room to explore and examine code patterns.
Conclusions
Pair programming, when done correctly is a powerful tool, but it can easily go wrong and ...
- Should never be forced.
- Should not expect different results or speed than traditional development.
- Is not about "showing off."
Images
Icons made by Freepik from Flaticon is licensed by CC 3.0 BY
Top comments (18)
I had a USB split keyboard and folks had a regular keyboard at their dock station. I would plugin my keyboard and we could both simultaneously type. Obviously that didn't work unless one person gave way. Yet we didn't need to move chairs to swap roles. We could swap in a keystroke then back. With screen sharing tech you often have to ”pass presenter”. This is really crude as is swapping seats. Just as we can concurrently edit a Google doc we should be able to concurrently type at the same IDE remotely and swap in a split second. When that happens it is like two cyclists working in a team to win a long distance time trial. They keep swapping who is in front to make a push and when they run out of stream the partner steps in and pushes for a while and they get to recharge for a minute and plan the next micro push. Swapping fast and frequently in my experience does get more done that one person working. Pair programming isn't about watching someone else work it is about thinking while they type then typing while the think and doing refactoring based in peer review in ”real-time”.
I’ve seen setups with the “extra keyboard” and I’ve tried the VS Code Live Sharing. They both have a solid places with both positives and negatives. Thanks for the perspective!
Live Sharing looks great thanks for that. I just enabled gitpod on my repos that lets me run a workspace with vscode in a browser but have not had a moment to try it. I also saw a video that eclipse che lets you run a vs code workspace on Kubernetes on a browser. So it seems that remote workspace sharing is now a reality for pair programming remotely.
And what where the positives and negatives?
The extra keyboard: positive, direct interaction with single instance of code. Negative, can’t look at other code while other person is typing. VS Code: positive, multi-individual interaction and allows for any file to be viewed and interacted with. Negative, needs “really” good internet connection; it can lag really badly.
I've never found traditional pair programming to be useful. Introverts find it painful to have someone watch everything they're doing, but might be too scared to speak up. Not worth the stress it puts on them IMO.
The strong technique falls into the same pitfalls that developers encounter when they blindly copy and paste code while watching a YouTube video. They miss the opportunity for their brain to connect the neurons while they work out the problem.
I find the rubber duck technique great for learning a new codebase, since I usually like to explore the code myself and then ask someone from the original team for help if something isn't immediately obvious.
Have to add to the rubber duck technique, even working on my own project rather a new codebase I find it helps just trying to run through what you are doing to someone unrelated.
Even in events where you don't get a response you pick up on something you have missed when describing what you are doing. Something about describing a process to someone forces you not to skip over things in your head.
Thanks for the insights.
Interesting - never knew all the different types of pair programming had names :)
Have you seen pair programming that happens over a long period of time (like, years?) I know there are companies that do ALL of their programming as pairing, but I just don't know how that would feel over a long period of time. Any insight there?
Are they pairing in and out over that time (single set of code) or is it just a matter of always being a part of a pair? Not sure I’ve seen or heard of anything like it ...
I think the most famous example is thoughtbot (could be wrong about that); but I know that some companies just do it a LOT more than others; and I was wondering if you had had any experience with that :)
Unfortunately, no ... I’ll keep an eye out.
I never had an opportunity to do pair programming. It feels like a good way to prevent the bus effect. Especially in small start ups.
I also wonder how pair programming can be feasible in small teams as there are already to many things to do for an extra developer. Any ideas on this?
Pair-programmng lower defects (more eyes on the task) also improve knowledge distribution in the team and remove or at least lower the need for code review. (Someone else already saw the code). With rotation of pairs everyone knows the code.
That is the theory if you do it right and spend some time and effort into it, to make it work for you and your team.
From my experience good pair programming session actually finish complex code/problem tasks faster. Cause you find solutions to problems faster. Also you don't miss less obvious stuff so often.
It is important to factor the time spend understanding other people's code which you had not taken part writing.
At least for myself I found out that is easier to understand code that I had participated in even if only watching other person writing it.
But it depends on the tasks at hand. If there are busy things that just took time like configuring some service, better work separately.
But writing and even debugging complex code/problem most of the time is fast enough and some times even faster then working separately.
In Pair developers are more engaged into the problem, more focused which is more tiring.
Thank you. This provided a good insight.
Excellent! Well said ...
I am happy that there is an actual article on this. I am a junior developer and the lead developer at the company I work for is such a fan of pair programming. I think I have learnt the most from pair programming and honestly i think it also saves the navigator time because he can multi task even if he has only got two hands.
I wrote a similar article recently.
7 Ways to Get the Most Out of Pair Programming
Personally, I love pairing even in a remote setting (we used Tuple for that).