Pair Programming is like sex. Done consensually and with the right partner, it can be a most beautiful and gratifying experience. Done under compulsion and with the wrong partner, it can traumatise you for life.
Pair-programming seems to be treated as a 'holy-cow' by many agile organisations. A sacred practice which should always be followed and yields benefits for everyone. "Pair-programming is great", I read. "Everyone should be doing it", I hear. Please excuse me while I call bullshit! I have done many pair-programming sessions in my career. Some as the navigator and some as the driver. I have also observed the impact from many, many more. Here is what I've learned:
There is no 'right' style of neuro-cognitive functioning. Not everyone's brain is wired in the same way. Different people learn in different ways. Assuming that the interactive, synchronous and intense learning model embodied by pair-programming is always the 'correct' one, has no valid scientific basis.
People have different biorythms. Some people are not fully functioning early in the morning or late in the evening, for instance. One of the best developers I ever worked with was unable to put two lines of code together most of the day. But in the evening, he was transformed into a highly-productive code-churning, white-paper writing, project-collaborating machine. My team used to joke that he was a 'were-coder', so radical was his transformation.
Good technical skills != Good communications skills. Just because someone knows their subject inside-out and can write beautiful and effective code, does not mean they can successfully impart their skills and knowledge onto others, least of all in an interactive and continuous manner.
Sociopaths work amongst us. I have noticed that software development attracts a proportionately higher number of sociopaths than other professions. Maybe it's because the sociopathic trait of cold, emotionless rationality is seen as beneficial in the software development world. Or maybe it's that sociopaths are attracted to money and our profession is a relatively well-paid one. I don't know. What I do know is that pair-programming with a sociopath, whether they are the driver or the navigator, is a traumatic experience for the unfortunate other member of the pair.
So yes, I have seen many cases of successful pair-programming. But I have also seen many others that ended badly. Some of the worst ones were:
The developer who was labelled a 'bad team-player' because he kept rejecting pairing with others. He was eventually dragged to HR, where he was forced to confess that he was on medication that made him short-focused and irritable and that was why he avoided pairing. Stigmatised and embarrassed he left the company soon after.
The developer who ran off in tears after their pairing navigator kept implying that they weren't intelligent enough to be a programmer, because they couldn't follow the intense pace of the navigator.
The new hire who quit after a month because continuous and constant pair-programming left her burned out. She was never given a chance to absorb knowledge at her own pace.
An asynchronous learning model. This is what we do when we go through code-reviews. But instead of waiting for the code review stage, we can implement a continuous asynchronous review process, where a developer posts their design, code or even thoughts on a special-purpose wiki (or a GitHub gist) in their own time and other team members can respond when and how they see fit. This gives developers the time to formulate their thoughts and assimilate the information received before asking the next question. It also gives reviewers the time to be more thoughtful about their responses.
Ping-Pong programming. This is a variation on pair-programming but it can be done asynchronously and is very focused.
A Mentorship model. This is where some team members are assigned as Mentors (or Subject Matter Experts) in specific areas or topics. The company allows time for these developers to help others in their chosen areas. Developers can then approach those Mentors to receive guidance on specific topics and within scheduled sessions.
Do not compel people to pair-program. Always wait for volunteering and mutual consent.
Ensure pair-programming happens in short, time-boxed sessions. Never allow all-day pair-programming.
Ensure pair-programming sessions are focused and scoped in specific areas,e.g. how to implement a design pattern, or the fundamentals of a new framework, etc. There should always be a learning goal at the end of a pair-programming session.
Do not advertise pair-programming as a company perk, or even as a best practice that should always be followed.
If you see a company advertising or boasting about pair-programming, run the other way and don't look back.
If you think someone could benefit from your knowledge or expertise, always ask them first if they would like your help. If they say yes, then ask them how would they like you to help them. Pair-programming should be one out of several options for you to help them.
If you need help from another person, always ask them first if they have the time or energy to help. If the say yes, then ask them what's the best way for them to transmit their knowledge. You should give them several options, including pairing.
Pair-programming is a sharp tool. It can yield tremendous benefits or do terrible harm. Use it with caution.