Outline:
But first, let's start with 0. WHY to do it.
Why to do it
I'm pretty sure the first question that comes to mind is Why?
Why should I pair?
Why would TWO engineers share the SAME machine and work on the SAME problem for hours or sometimes for multiple days?
Well, pairing brings many benefits.
Here are a few we want to highlight:
1 - HYPER FOCUS (A.K.A MONOTASKING) - Pairing keeps you and your pair super engaged as you will not access slack, email, or any distracting website while you have someone else watching your screen or right there counting on you for help.
2 - Pair programming is also CONTINUOUS "RUBBER" DUCKING. You have someone there to talk to you, unblock you, catch your mistakes, or give feedback on your code ALL THE TIME.
3 - Pairing is a fantastic way for ONBOARD NEW TEAM MEMBERS. A great way to work on real problems, answer real questions, and explain codebase/architecture details as needed instead of reading documentation for days to find out only much later that they were not up to date.
4 - Pairing is also a risk-mitigation strategy. Pairing helps to decrease what is known as "THE BUS FACTOR." That comes from this question: > "How many people could be hit by a bus without any impact on your project?"
Two other Lesser-Known Benefits of Pair Programming:1) Flow is easier to recover. If one of you is interrupted, the other can remain in a flow state and quickly bring you back in.It reduces the impact of interruptions.
Two other Lesser-Known Benefits of Pair Programming:2) Your hands get a break. RSI (Repetitive Stress Injury, can be caused by excess typing) is no joke. It can end careers.Pairing lets you share the typing and put fewer miles on your tissues.
WHEN?
1: The most obvious reason to pair program is when you're stuck. Bringing in a second mind is a great way to get unstuck.
2: It's okay to start a slack chat about a programming question. But if that chat goes back-and-forth —especially in real-time — that's just not efficient. So make that an internal trigger that it's time to look at the same screen and talk about it.
3: To save time when you're making design decisions. The thing is, as developers, we're almost always making design decisions. Sometimes these are big decisions around architecture. Sometimes these are more minor decisions, like how to name something.
4: Pairing reduces the delivery time of that one item. Of course, two people can work in parallel on two problems. But, working together on the same problem makes solving that one problem faster. So, it reduces the delivery time of a single item, not the throughput.
5: And finally, pairing is a chance to learn skills from your partner. It isn't about junior engineers vs. senior engineers. Pairing is a chance for old dogs to learn new tricks and new dogs to learn some old tricks!
When NOT to Pair?
There are probably more scenarios, but these are the big 2 reasons to avoid pairing in my opinion:
1- Talking about decisions again, whenever you are not making decisions or a REALLY small amount of them, pairing is not a great use of two brains.So, if it is a repetitive task or just following instructions that both engineers are familiar with, pairing is not a good idea.
2- Whenever you need to study a new framework, to research, to explore many options, you might need your own time to do your reading without somebody talking or watching you.You and your pair can connect later.So, pairing is probably not a good idea while researching.
New Addition - When to Pair vs. When NOT to Pair:This is a matrix from a paper. One caveat is that programmer expertise is not necessarily years of exp., but experience on that codebase/tech-stack/domain. So you can be a Senior eng. but still a Junior on the project/codebase
TIP NUMBER 1: Use or Try the Driver/Navigator pairing style.
In pairing, it's helpful to adopt different roles. Like two people on a road trip, you can have a Driver and a Navigator.
The Driver is doing the typing and can focus on small details.The Navigator keeps an eye on the landscape and can focus on the big picture.It combines two styles of thinking: The Driver can do "tactical thinking", while the Navigator can focus more on "strategic thinking".
Use the microphone close to your month, BUT NOT TOO CLOSE or not too far away.
Avoid the computer's microphone or speakerphone at all costs. Room echo and any background noise will make it super hard to understand what you're saying and super annoying to the other person.IN SHORT, YOU NEED A GOOD HEADSET and a GOOD MIC FOR REMOTE PAIRING.
Remote pairing, in particular, is all about GOOD AUDIO QUALITY,It is one of the things that has improved a lot since the beginning of the pandemic.
Breaks.
You need them.
Plan for them.
> "Professionals take breaks. Amateurs don't. Breaks are part of performance. They're not a deviation from performance." – Book: When: The Scientific Secrets of Perfect Timing by @DanielPink
Pairing and, in particular, REMOTE PAIRING is really exhausting. So, make sure to do regular breaks, OR otherwise, you will be dying after a few hours.And REMEMBER, pairing is all about having a good experience.
It needs to be something that both parties enjoy and look forward to. Not something painful.Regular Breaks make the pairing experience less exhausting and a lot more productive and fun.
How to switch remotely?It's helpful to switch who is driving reasonably regularly — at least once every hour, maybe once every 15 minutes.To avoid the lag that comes with remote keyboarding, just switch the work from one computer to the other
An easy way to do this is by using a shared branch.
"In this image, Thiago can just commit and push, and I can pull. Then I become the Driver and share my screen."
`$ git commit -mWIP & git push`
More often than not, you will pair with somebody with a different display or completely different screen resolution than yours.
As a Rule of Thumb, always use the smallest resolution of the two as a baseline.
AND REMEMBER, REMOTE PAIRING IS ABOUT A GOOD AUDIO & VIDEO & SCREEN SHARING EXPERIENCE, not only for ONE SIDE, for BOTH sides.
References
If you want to know more, here are two of my favorite articles on pairing:
1- The first one answers pretty much every single question you might have on pairing.
2- The second one answers one of the most asked questions: What does an Effective Navigator do?
Links:
- On Pair Programming by: martinfowler.com/articles/on-pa…
- Effective Navigation in Pair Programming: https://www.thoughtworks.com/en-us/insights/blog/effective-navigation-in-pair-programming
Books:
Three books that talk a lot about pairing/tools that I recommend.
