Taming of the Pair Programmer

In a recent project at work, I went through an intense experience of pair programming with some of the thought leaders in pair programming work model. While I enjoyed the experience, I do feel that pair programming psychology has been given a serious miss.

So I visited the world famous psychiatrist Dr. Pear for consultations but unfortunately, the notes were leaked out due to a security breach from the cloud platform where the medical records were stored. Here is the transcription.

Dr.Pear: Hello! (looking at my records) May I know the reason for your visit today?
Me: Sure Dr. Pear. I have been having some delusions about pair programming and I want to understand how to overcome pair programming anxiety.
Dr.Pear: (notes down): Oh, a case of PTPPSD (Post Traumatic Pair Programming Stress Disorder). Have you tried the OTC medicine – Pairitin ?
Me: Yes, doctor. But it hasn’t helped, obviously. Placebo.
Dr.Pear: Oh, well … Ok, I have a few questions. Can you describe your regular office day?
Me: I check my mails while driving to office, reply to them on the elevator, get a cup of coffee, then find a pair and start doing things. We switch roles of driver-navigator till the end of the day. And the next day we switch pairs and do the same stuff.
Dr.Pear: Sounds normal. What about breaks?
Me: Yeah, we do take breaks. And I always explicitly communicate what I am about to do – whether its bathroom breaks, get coffee, drink water, check my personal emails, answer my phone, stand up, sit down or shake my head. One time I experienced a TalkOverflowError, by recursively saying “I am about to talk” before actually talking. I have come to believe that Pair programming is just a catchy name for “Thinking through mouth”…
Dr.Pear: How do you feel about the quality of work?
Me: Its definitely improved. It has helped me identify minor bugs pretty early, that could have been a pain later. But there are times where I have completely rewritten my code at night, after an all day unsuccessful pairing.
Dr.Pear: Yeah, I have heard that happen. In general, do you feel you are productive?
Me: Sometimes yes, sometimes not. It does take longer time to achieve things initially.
Dr.Pear: Thats natural. Pairing is a trade-off between delivery-time and knowledge-spread. Its an insurance against concentrated knowledge. The preimum for that insurance is the early time investment. It also psychologically eliminates situations to unfairly blame others like ‘I cant touch that person’s code, I dont know what’s in there’. Eventually, its all about hitting the sweetspot of productivity. It does take some trial and error.
Me: Ok, I get that… But I have also developed some phobias recently, like mysophobia
Dr.Pear: These are side effects of this disorder. When you are pairing, you have to ensure that your personal hygiene is never compromised, especially if you are sharing the keyboard and mouse. Always clean your keyboards, do not eat while typing and wash your hands often. And don’t ever fall sick.
Me: Should I shower everyday?
Dr.Pear: I’m going to pretend I did not hear that…. now, this may sound unrelated, but nevertheless, how much time do you spend with your wife everyday?
Me: 1-2 hours?
Dr.Pear: …not including like helping with dishes, watching TV, you know.. just sit around..
Me: Just sit with her?
Dr.Pear: Yes, just quality talk time…face to face…husband to wife…
Me: 15 mts..?
Dr.Pear: So you spend 15 mts with your life-time companion everyday, but sit with your coworker for 8 hours straight talking face to face about every action you do?
Me: Apparently, Yes.
Dr.Pear: Hmm, recent scientific studies have proven that any amount of time spent with a coworker as a pair more than that you could with your own spouse is detrimental.
Me: And which study is this?
Dr.Pear: Its called the Pear’s Pair Limit. If (time-spent-with-pair > 1.5*time-spent-with-spouse), you end up in whats called Productivity Blackhole.
Me: I see… Does that mean I can pair only for 15 minutes a day?
Dr.Pear: Or you could spend 8 hours of quality talk time per day with your spouse…
Me: (blinking and awkward silence)
Dr.Pear: Got yaa! Ha ha ha! You developers always fall for that… Ok.. how about remote pairing? Like with people you have never met before face to face.
Me: Happens all the time… This one time, I ended up talking on headphone for over 10 hours. I ended up with a soar throat and my younger kid wondered why I was talking to the computer all day long.
Dr.Pear: Ha ha ha! Your kid is very observant, indeed.
Me: ???
Dr.Pear: Was just kidding. (murmurs) Get some humour, you techies… Anyways, so who else practices pairing in your office?
Me: All programmers, of course.
Dr.Pear: No, I mean pairing, not just pair programming…
Me: I thought pair programming is meant for programmers, Duh!
Dr.Pear: Er.. not exactly. Again scientific studies have shown that pairing is beneficial only if applied at all levels of an organizational structure. You know, like you can’t have one agile team and the rest of the organization is waterfall. At the programmers level, a risk of a bug usually costs much lesser than an issue that is not addressed at the architecture or management level.
Me: So like a Pair Architecting, Pair Managing?
Dr.Pear: More than that. “Pair Resourcing”. A programmer’s bug is lot more tangible, than a decision made at an architecture or management level. While a code defect can be fixed by some other programmer, “fixing” a wrong decision at the management level by another manager is usually very expensive. The higher the level of management, the costlier the fix.
Me: Ok, I get it now… An organization should always hire two people for the same position?
Dr.Pear: No. I meant more resposibility-spread in all levels. Imagine your reporting manager, who knows and appreciates all your hard work, quits. And your new manager is like Clark Gable from Gone with the Wind. A pair reporting manager would still know your work and share that with the new manager. The same technique goes all the way to CEOs.
Me: I see…and how is this measurable?
Dr.Pear: Pairing effectiveness can be measured quantitatively. You have Resources on the X-axis, Domain on the Y-axis. More vertical dots means one resource knows more stuff. More horizontal dots means many people know one stuff. Ideally connecting dots of edges will form a rectangle – everyone knows everything. Realistically it is a histogram. This is called Pear’s Knowledge-Responsibility-Spread graph. The closer the ratio of area of rectangle to area of histogram to 1.0, the better the organization’s base.
Me: Ok, I feel a lot better now. I think…
Dr.Pear: Sure, glad to help. Also here are a few business cards, please distribute in your office to your pairs and managers.
Me: (hesitantly) Er.. .Thanks!

Dr.Pear seriously types some notes about me on his laptop. I glean over him gently and looking at the screen and say “Er… doctor, I think you have a typo, you spelled my name incorrectly…”

Dr.Pear: What? Are you trying to pair with me now?