| > Forgetting it’s a skill > Pair programming is a skill which must be learned. > You will not be good at it at first, but consistent practice will yield improvements. > Don’t give up after a difficult first experience. Don’t assume experienced developers are automatically good pairing partners. Don’t expect to be good without practice. > Consider reflecting with your pair or asking for feedback after each session. What could have been better? In my experience (pairing on and off for about 12 years) - this is the biggest thing people misunderstand about pairing. You're not going to be good at it right away, and the team isn't going to benefit right away. It's an investment that pays off in months not days. That being said - I find that requiring my team to be good at pairing, but not that they pair all day every day, is sufficient. It means that they pair when it's appropriate (onboarding, larger design problems, early stages of a project, etc) and they don't when it's less appropriate (fleshing out an implementation, exploring a new idea, mundane updates). We find that if we pair all the time, especially on things that don't benefit from pairing, it exhausts us. Pairing is a useful tool, but it can be equally dangerous if overused and cause people to resent it. |
For example, with one co-worker at the keyboard, I would fully take on a support role: He was a slow typist, so I'd keep an eye out for typos and quietly nudge him instead of having to wait for a compile/run loop, I'd look up documentation so he wouldn't have to keep context switching, and so on. Before that point though we had roughly equal roles at the design stage (he was a very strong proponent of "keep it simple" and made me realize I was drifting into an "architecture astronaut" mindset, so I think we worked really well together overall).
In another, with some co-workers unfamiliar with a codebase but wanting to learn more, I'd take the high-level guidance role where I'd be mentally working a few steps ahead on the overall design/goal while they worked on the nitty-gritty details. They'd be learning how the pieces fit together without having to worry yet about side-effects or other problems because I'd be acting as guardrails, keeping them on the right track and identifying those problems ahead of time so we can deal unavoidable ones right away. Ideally this role doesn't last long with anyone as they'll need to learn those parts on their own, but it works sometimes.
As a step up from that second one is on/off pairing, where they'd be testing their knowledge on their own to come up with a solution, then we'd pair for a while to make sure they're on the right path and maybe get past a spot where they were stuck on how to do something.