When I tell people that most of my team pair 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 realise 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”
Diary of a ScrumMaster 
This is such bulls#it. I am an experienced developer (more than 20 years) and I adjusted myself to announce each time I make a programming mistake. Apologizing to the person it affected in the team and fixing it as quickly as possible. I know what vulnerability is, and yet, pair programming is stupid and dangerous; it will always be on the brighter person to drag the lesser one with him/her, it will always end with one or both of you feeling like you wasted your time and it will always end with being less productive (sometime much less so) than just leaving me be.
This scrum business is one of the stupidest fads I encountered in the business and pair programming is one of the more idiotic things in it. The whole agile movement was created from business management perspective, it downsize developers to be cogs in the system while pretending to make them self sufficient and independent. I got a lot more to say about this awful scrum business but it will wait for another day…
Wow, I’m really sad you feel that way about agile. In my experience it very much came from the developers not from the management, we chose it and chose to continue with it.
I understand that not everyone likes the idea of pairing. Again it’s never been forced on our team but we chose to do it and have done for 5 years. In that time the team has grown hugely and delivered more than we ever expected.
Having said that I know lots of fantastic developers who don’t pair and don’t like agile. Whatever works for you.
I can’t remember when I’ve seen a better parody of how outrageously ignorant the larger software community remains to the goals and culture of lean software development. Very post-modern and highly entertaining. Almost authentic enough to make me believe that you actually meant any of this. Nice try.
“lean software development” in a post about pair programming, where programmers are the single most expensive part of any project. Hilarious.
Well said. +1.
>it will always be on the brighter person to drag the lesser one with him/her”
It is fascinating to me how most non-pairers assume that it a pair situation there is always a “brighter” and a “lesser”. This seems very arrogant. Programmers have different strengths, and the power of pairing is to bring out the best of both, and for each to learn more as they go. This idea that the better coder will be dragged down is mostly myth, only possibly true when the people pairing have a “I’m better than him” attitude. Not really fertile ground for learning.
Apologizing for a mistake after the fact is much less useful than catching a mistake in progress, and adapting as you go. The former is easy—it requires merely a statement; the latter is much harder as it requires real dialog.
>it will always be on the brighter person to drag the lesser one with him/her
I’ve done my fair share of pairing and that’s how it feels to me 99% of the time. It might sound arrogant but the reality is that not all developers are created equal. They have varying level of motivation, potential, abilities and experience. And there are few projects staffed exclusively with super hero level developers.
If decisions constantly swing one way (based on rational arguments) there is very little point to having that discussion in the first place. You are not being more productive you are just schooling the less experienced developer. Now this may be a goal on it’s own, but then I believe that people learn by failing, not by someone whispering the correct answer in their ear.
The science seems to support this btw : http://itsadeliverything.com/research-on-pair-programming-by-professionals
Thank you for this link, supports our views.
Hi, Thank you for taking this seriously and not dismissing it.
Tobias, I did some pair programming and it’s fine, but its was a very unenjoyable experience.
Tom, don’t be sad, I can only hope you’ll understand what is bad with agile and strive to fix it. As from who it came from, talking to some NYU prof who is an agile evangelist it very much came from the management layer; the problem was that the previous method of doing stuff (waterfall) created long change lists and a middle management nightmare, so the answer was to roll it onto us the engineers.. This is a patch on a patch, its not a solution built from the grounds up.
I think that the real solution is to discipline the customer, set expectations and stand by your programmers, and not lie down and get stomped over by the client. This is divided into to things: one is what happens if you do something and the client asked and/or expected something else and the other is feature creep. Setting expectations and being in constant contact with the client is the solution for the first one, management should be a conduit for this and dumping it on the engineers is not an answer. The second problem which is feature creep is also a managerial issue and I understand its part of an ongoing relationship with the customer but it must not hinder the release schedule (you can move the TTM if you like).
Now you see how this trickled down to our level? judging by the name of your blog I take it you are one of us, an engineer who is a scrummaster, if that is the case I hope you’ll see the light and stop drinking the kool-aid; by trickle down I mean that us, as engineers, are trained to solve problems, and agile is a try at a solution for a problem we did not create, first we were approached by middle management who said waterfall is not working, then we came with an answer: lets tie our work with the client’s – pigs and chickens and so on, then came the great cognitive dissonance of why this solution is so clever and good (getting a swing on a tree that does not exist when the client wanted a jet).
I feel like I am not getting my point across. There are good things in agile but the original problem it tries to solve is the wrong one. If we would really like to be agile we need to take each team member’s strengths into consideration and not clamp everything into stories, epics, tasks and what have you so people can put our work into graphs and track our work.
Told you I got lots more to say, didn’t I ?
Hi Paul and Andre
Thanks for your comments, yes I am a developer as well as a Scrummaster. To get the easy bit out the way, I’m really with you that agile should not be forced on anyone. I think it’s the team decision to choose the way they want to work. Believe me, there is real concern in the agile community that it is being forced on people and I understand your anger.
The issue you both raise, about the problem being that the management is not able to tell you what is needed is more tricky. The best way I’ve found to solve this problem is for the dev team to work with managers and customers to help them with this. I think that is what you are objecting to. I’ve found there is a lot to be gained from moving beyond the “Us and Them” culture and actually collaborating. This doesn’t take much time. Our team still spends most of there time with their head down coding (even if it’s not alone) sometimes we still zone out on our own too. A small amount of time spent sticking our heads outside of the team seems to be hugely beneficial for all parties, so we do that too.
We do what we have found works. I’m sharing my experience. I’m not trying to tell anybody how to work or judge what they do in any way. I think most of the agile commuinity is the same.
I think your point about
“I did some pair programming and it’s fine, but its was a very unenjoyable experience.”
We did an XP experiment about five years ago, with an intent to prove or disprove the usefulness of XP in the environment we were working in. Up front, we had a commitment to try to hard to do it “by the book”, ie. not cherry pick the “easy” ones and so on. It took the team members about two months of “we’ll pair every single line of production code” to really feel comfortable with pairing. The first month there _was_ a feeling of “more experienced one being dragged down, while for the junior it all went well above their heads”. However, after that first month the feeling started to disappear as the juniors really picked up things fast (fastest learning I’ve really ever seen, for everyone) and were able to contribute to the effort almost equally. At this stage, pairing became a continuous “high five” as the pairs tackled together a problem after another. The people said that this project is way more fun as any other project they’ve done, because they’ve been sharing all the high points together.
At the end of the project, I asked the team that if they could only take one XP practice to the next project, what would it be. The team chose pair programming.
“As from who it came from, talking to some NYU prof who is an agile evangelist it very much came from the management layer.” You can’t have this more wrong, although I can absolutely understand why you’d have this impression.
If you’d like to know where this *really* came from, starting reading here: http://www.xprogramming.com/Practices/xpractices.htm
It came from programmers trying to figure out which parts of their work were essential and which were ceremonial, so that they could stop the ceremonial parts and get better at the essential parts.
I think people need to come to terms with the fact that not every Software Developer wants to permanently interact with other people, which is the reason why many of us became developers in the first place. For me, I find extreme pleasure in zoning out into that blissfull world of coding, headphones on and music of my choice. After all, I would like to think that we chose our careers because we are passionate about what we do, and for some, talking to another person all day is as appealing as collecting garbage bins for a living.
I do find great value in pairing up on occasion when trying to solve difficult problems, but if it became an absolute requirement I would find another field to work in.
As for scrum evangelists, and the scrum movement, it’s just becoming regurgitated bla bla. I’m really sick and tired of it, and I sincerely hope that people don’t mistakenly assume that the scrum movement is the mouthpiece for software developers, because they are not. We are too busy coding to care. Maybe if we had several hours a day after stand up to twiddle our thumbs we could also become evangelists of sorts, but what started out as a good idea, has been hijacked by the biggest con artists in the history of software development.
Excellent reply Andre, I agree.
“I find extreme pleasure in zoning out into that blissfull world of coding, headphones on and music of my choice”
Sounds very good :). It’s a delight. Now imagine, zoning into a blissful coding, with a colleague, and together to solve challenging problems like a machine gun. Every time you get stuck, your colleague comes to the rescue, and the next moment you help him/her.
It seems that pairing creates that “flow” with the two people involved. And it seems to be stronger than personal flow. A fellow coach noticed that whenever he went behind a single person (with headphones or without them), that person would turn around and be interrupted (which is a good reason to leave zoned-in individuals to themselves, or lock them up in rooms). However, when he similarly approached a pair, most of the time they were essentially oblivious to his presence. He interpreted that to mean that the flow the pair created was already involving the social context of the other person, and was less fragile to external factors.
I notice the same myself – if I try to work on something (I don’t code anymore, sadly) alone, I’ve very disturbable. But if I pair (e.g. in a workshop or at the table), I’m much more focused and that flow is much more sustainable. I feel energized by pairing.
And to add more context to my thinking, I see pairing as an instance of swarming. I define swarming as “the bigger the problem, the more people we throw at it” (rather than the traditional “the bigger the problem, the better a person we throw at it”). A pair is when two people pair. Pairing is worth doing when the problem to be solved is big enough, e.g. when writing non-trivial production code. If a problem is really big, get three people involved, or more.
There are many activities in a typical project which are _not_ worth pairing. Obviously, it’s up to the team to discover / decide what they are. I’m sure it’s not worth reading emails as a pair…
> I think people need to come to terms with the fact that not every Software Developer wants to permanently interact with other people, which is the reason why many of us became developers in the first place.
I have worked with people who simply couldn’t pair, for exactly the reason that you cite here. For some, it went far beyond mere preference to a deep part of their personality. One person had to quit because the rest of his team agreed to start pairing as SOP and he couldn’t handle it.
We often push people to try pairing because we benefit so much from it and we want others to experience that benefit. We think we’re doing people a favor by helping them push through their own limiting beliefs. I don’t think that way any more, and I feel bad that I ever did. I invite people to pair with me, and I try to give them the best pairing experience I can give them. I don’t pressure anyone to do it. That seems to work well enough.
“… but what started out as a good idea, has been hijacked by the biggest con artists in the history of software development.”
That happens to every good idea. All of them. Every single one. People don’t try to exploit crappy ideas. Life includes a struggle to stand up for the good ideas in which we believe and warn others about the con artists. It seems that it can’t be any other way.
I’ve been a programmer in one form or another for almost 20 years. I beleive I’ve noticed a trend as more younger programmers join the workforce, of there being a shift away from the stereotype of the isolated, loner, programmer to a much more social one.
These newer guys are, generally speaking, far more open to pairing and emerging practices and as the trend for them grows there will be more demand to recruit people that are willing and able to do so. In my opinion.
Taking the view for a second that pairing is a fad, makes it no less real. Many of the management, or technical practices we see and use could be considered fads. Take any programming language for framework for instance.
Wikipedia describes a fad as “A fad is any form of behavior that develops among a large population and is collectively followed with enthusiasm for some period”
My point here isn’t that you are right or wrong about your stance on pair programming. It’s about the change in cultural norms that we are exposed to and how they affect us. Whether you think pairing is a good or a bad thing, it is a growing form of behaviour in the programming community. It’s an evolution (after all, fads are a neccessary part of evolution). If a new cultural norm takes hold, we can choose to embrace it or exclude ourselves. Tom is choosing to embrace it, others are choosing not to, perhaps at the risk of excluding themselves from the momentum that might make it a success (or failure, only time will tell) .
I for one think it’s an incredibly rich technique, when practiced in a culture that supports vulnerability and promotes trust and sharing, can only improve the daily lives and sastifaction of programmers and the quality of the products they produce. A problem shared, is a problem halved.
[…] it takes courage and vulnerability and that scares people and we should be mindful of that. My post “The Shame of Pair Programming” is attracting a lot more attention than I’m used to. The comments range from “I feel […]
[…] evening after this meeting I read The Shame of Pair Programming, by Tom Howlett. It’s a great, short read about how bad pairing can be demoralizing. […]
[…] 53:47 – Tom Howlett: The Shame of Pair Programming […]
I think pair programming can be useful and even enjoyable occasionally in certain situations but it’s not something I would do on a regular basis. Sometimes I need to read, to think and to experiment for my work and I would be annoyed to have someone talking and looking behind my shoulder. Talking and listening someone non-stop for 6 to 10 hours a day can be very exhausting. I know only one person who wish to work only in pairing and in my opinion it’s more a personality trait than a wish to make more quality code. That person need to talks constantly and feel very uncomfortable to take decisions and hates individual work.
I prefer work in an environment where communication and team work is important and people help each other but where individual work is done most of the times.
From reading the Wikipedia entry on Pair programming, there still isn’t any evidence that it is beneficial for a team.
More importantly, Susun Cain’s recent book, Quiet, makes it clear that a large proportion of us are unable to think when pair programming. Some the most creative among us are at their most creative when left alone to think inside their own heads. She quite rightly points out what so many of us see is so wrong with the new ‘New Groupthink, which holds that creativity and achievement come from an oddly gregarious place.’
Scrumasters need to value those that that prefer to work alone as they may well be their most creative and productive members of the team. I can see why pair programming might be reassuring for some, but please respect those of us who are creative and productive precisely because we are the personality types that are unable to think whilst pair programming.
Also, to the person who noted that the younger, newer team members are more open to concepts like pair programming. You realise people trying to get a start in a career have little choice but to do what is asked of them.
I haven’t read Susan Cain’s book yet, but have read other similar books, like “The Introvert Advantage”. A serious issue is that some people just don’t get it.They assume that everyone is like them, and what works for them must work for others. Its the same with the games scrum masters come up with. Some of the team are giddy with delight while others are going “Someone, just kill me now, please”.
[…] The-shame-of-pair-programming […]
[…] — Tom Howlett […]
[…] — Tom Howlett […]
[…] 『The Shame of Pair Programming』Hom […]
Chelsea are next to guaranteed Champions League football next term and will not have the luxury of one game a week next season.
[…] — Tom Howlett […]