Saturday 17 December 2016

Pair Programming – what’s in it for me?

There are many advocates of Pair Programming explaining why they think this way of organising software developers’ work is good for the company. But I have not seen much explanation why it might be good for a developer. We, developers, usually enjoy what we do and care enough for the success of the projects we work on, but I don’t think many of us would get up in the morning and commute to our place of work if there was something for us as well – we would like to be paid well and we like to have a career. This means that our choices are not defined by what good for the company but also what is good for us personally.

Pair Programming was around for quite some time (XP is here since 2000), but I have a feeling that recently I am hearing more about this then I heard before.
Interestingly I also have an impression that when hear about 100% pairing, it would normally be either involve an IT consultancy practising it or people who in the past used to work for one of IT consultancies.

I suspect there is a reason for IT consultancies to practise pair programming – you can charge for two people doing the same work (explaining that “it improves the quality”) and it would allow them to send to a customer an inexperienced developers paired with one that have experience while charging if they both were experienced.
I can also understand why managers might like it – it allows them to see developers as an exchangeable “resource”, eliminating a “bus factor” while at the same time ensuring that the developers police each other in terms of actually “doing the job” and having even to inform each other when they go for a pee.

What I don’t understand is why some developers support this?
Do people really want to be sitting next to someone else at the same desk day in and day out instead of having their own place in the office, which they can personalise the way they like (pictures of kittens, Star Wars poster or whatever else their personal kink would be). Don’t they want a place where they don’t have to suffer because someone else has poor hygiene habits?
Do they want to be able to use any IDE they fancy and setup their machine to whatever weird configuration they favour, or do they prefer this decided by a “committee” and they been forced to follow rules?
Do they like to be “one of the pair” instead of “that guy who did that cool thing”? Are they feeling too insecure in their professional abilities that they are afraid to work on their own?
How do they see themselves in 10 years time? Still be a faceless member of a “Team” members of which are not even trusted to work on their own at their own desks?

Talking about personal interest as far as a developer concern I can see only disadvantages:
-       It is more difficult to demonstrate your own abilities and worth to the management if they never see your name attached to anything unless it is with other person, hence less chances of career advancement based on your own abilities as a programmer.
-       The management sees you as replaceable (as far as they concern there are always other people available to do your job, everybody you are pairing with are good enough candidates).
-       You have less freedom over what you do and how you do it – you have to explain every step to your pair and you have to coordinate with others all your activities
-       You have less comfort in your workplace, as you have to share space in front of the screen with someone else.


  1. You don't have to share space the entire time. It should just be used when you need help with something. "Oh do you know about this interesting problem, maybe we should pair for an hour on that?" These are the types of conversations that happen in my office.

    You get the advantage of learning a new skill and in my experience I have seen none of the disadvantages you claim in my own work or any of my colleagues.

    I recommend you give it another try. There's a lot to learn from other programmers and if it isn't fun or interesting you're doing something wrong! :P


    1. And for how long one should persist on trying any stupid practice someone else find useful for them?
      In my experience the best programmers tend to dislike this practice, so I have no reason to try this again, especially as it is not really good for the standing of the profession.

  2. I've worked for a place that did a pretty good job of discouraging pair programming. And I've worked for a place that made it mandatory. Now I do it about 50/50 and I think that's a good balance. When it makes sense, like onboarding someone new or sharing knowledge, we do it. When there's something like research or really digging deep into a problem, and it doesn't make sense, we don't.

    1. People are different. I found that I personally learn new stuff better when I am left along with the problem.

  3. The question "What's in it for me" is one reason why the software industry is in the sorry state it is. Pair Programming is not about "me", it's about the project and it's success.

    1. I go to work because I like to be paid and because my jobs seems to provide some pleasant moments. I don't do it to increase my employer's profit as a result of project success.
      Yes, I work hard and being a professional care about the results, but I want it to be noticed and I want to be rewarding for it.