Agile Zone is brought to you in partnership with:

Tom discovered Agile Development in 2003 and spent the next 8 years, together with his team at, improving their process and blogging about his discoveries. He has a particular interest in the psychology of keeping Agile agile and not letting it slip back into the evil old ways! He believes a Scrummaster should also be a developer and codes ASP.NET and C# most of the time. Tom is a DZone MVB and is not an employee of DZone and has posted 44 posts at DZone. You can read more from them at their website. View Full User Profile

The Shame of Pair Programming

  • submit to reddit

When I tell people that most of my team pairs most of the time, and that it’s not mandated, they nod and say “Yes but I don’t think my developers would be happy doing that.” But that’s as far as we go. Why are people reluctant to pair?

To pair requires vulnerability. It means sharing all that you know and all that you don’t know. This is hard for us. Programmers are supposed to be smart, really-crazy-smart. Most people look at what we do and say “I could never do that.” It makes us feel a bit special, gives us a sense of pride and pride creates invulnerability. I often hear stories that infer “I’ll just go and do some magic and if it takes a long time you can bet I made miracles happen.”

When done well, the shame of pairing quickly evaporates. As you start to realize that, between the stuff you know and the stuff they know, you can be twice as good, pairing becomes joyous. Together we find solutions that would be out of reach if we were alone.

Sometimes I pair with someone who keeps chipping away at my confidence. If I had more courage I would let them know how each comment makes me feel and suggest a more constructive alternative. Yes this courage takes and even more vulnerability, which is particularly hard when they are filling me with shame by pointing out my incompetence.

It’s hard. Pairing well takes empathy, empathy evaporates shame, allowing courage. As Brené Brown says “Vulnerability is the birthplace of Innovation, Creativity and Change."

Published at DZone with permission of Tom Howlett, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Byron Palmer replied on Wed, 2013/10/02 - 11:59am

You should read Quiet about introverts. I am not someone who works well in a group environment as most introverts do. Asking for creativity in an environment that is uncomfortable is not a good idea. If you are an extrovert then this might work well. It has nothing to do with vulnerability for introverts but with comfort and stress. If you want people to learn from others then I suggest other processes such as code reviews. One of the big failures is the whole idea of collaboration all the time will make things better, groupthink, brain storming, and other rot like that. 

Maybe pair programming works for you, and maybe if you only hire extroverts you will be fine. But I would never work in that environment, and if I ever was forced to I am sure I would not be as creative as I am now. I do work with others, talk through problems, ask for suggestions, but not all the time, and not in a forced manner.

Tom Howlett replied on Wed, 2013/10/02 - 3:12pm

Thanks for your comment and book recommendation, Ill give it a try. My experience and that of many others I have spoken to about Pairing is that whilst initial uncomfortable it soon becomes the preferred way of working. I would say that I work with a team of introverts, it takes courage to start but is hugely rewarding if you overcome the initial fear. If you want to read about other peoples experiences and fears about pairing check out the comments on the original post

Lund Wolfe replied on Sat, 2013/10/05 - 6:17pm

I have to agree with Byron that this will only work in a development environment that fosters risk taking and isn't fear based.  It also requires a certain level of individual maturity, humility, and mutual respect (hopefully deserved).

Vulnerability precedes growth.  I've only done a tiny bit of pair programming, but I think I understand the potential upside and downside.

We developers often have strong biases and group efforts require compromise.  In this business the minority is often right, and even when it isn't, feeling empowered is a huge contributor to enthusiasm and productivity.

I assume that there is more of a stream of consciousness rather than considered deep thought.  This can be good or bad, depending on the situation.  Two heads are better than one in that you will have one developer catching many poor choices made by the other.

Two developers playing on each other's strengths can potentially far exceed the power of two brains working alone.  I suspect this is highly dependent on finding a good pairing, though.  The social aspect can also generate enthusiasm and forward momentum in otherwise tedious or repetitive work or frighteningly undefined work.

There is also a fundamental question of whether it is better to concentrate the better developers on the more difficult or important projects or parts of projects or use them more thinly across all development and share the knowledge and skills with others on the team.  Everyone learns skills, application knowledge, business knowledge from everyone else.

I do enjoy working at my own pace and spending as much time thinking as I like.  Sometimes I am creative and energized and sometimes I'm more of a vegetable.  One benefit to pair programming is that both can contribute something continuously to achieve a steadier pace.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.