21 ways to hate pair programming

Every time I’ve had the chance to talk in detail with people who hate pair programming (where two developers work jointly on the same task, usually sharing one computer, screen, and keyboard), I discovered that they were doing it in a way I too would have hated.

Below is a list of mistakes I’ve heard or seen real people make, including many that I’ve made myself. If you think pairing is not for you, first check to see if you and your team have solved all of these problems.

How to pair badly

    1. Hog the keyboard – You’re obviously superior to your partner. Control the action at all times.
    2. Ignore your partner – That noise that sounds kinda like useful suggestions? Probably a mosquito.
    3. Ignore yourself – Speaking up for your own interests can’t possibly be helpful. Suppress, suppress, suppress!
    4. Sit where you can’t see – You’ll be able to read the code when it’s your turn. If you still care then.
    5. Sit where you can’t reach – Why be ready to take action? There’s probably not much you can do anyhow.
    6. Take a back seat – Don’t sit next to your partner. Sit behind her. Then she doesn’t know when your eyes are closed.
    7. Use a regular desk - Desks set up for one person work even better for two. Plus, the furniture police might catch you!
    8. Don’t explain – Your partner, who is psychic, can just read your mind. Just keep on typing!
    9. Don’t listen – You already know what your partner is thinking. And it’s boring.
    10. Don’t ask – No, there isn’t a better way to do it, and your partner never forgets anything. So hush.
    11. Interrupt frequently – ZOMG! They made a typo! You’d better tell them right now. They’d never notice otherwise.
    12. Get distracted – Look, new mail! Hey, an IM! And check out Slashdot! Wait, there’s coding going on?
    13. Daydream - Since you’re not really there to help, it’s ok to figure out exactly how many light bulbs there are in the room.
    14. Be a back-seat driver – Your partner always wanted to be a stenographer. Keep telling them just what to type.
    15. Don’t take breaks – Everything is better when you’re tired and cranky. Especially teamwork!
    16. Work too much – It’s not what you create. It’s how many hours you spend at your desk.
    17. Ignore ergonomics – The hunchback look is back in fashion. And who doesn’t like pain?
    18. Betray trust – During, taunt about minor knowledge gaps. After, tell everybody how dumb your partner is.
    19. Refuse to learn other tools – Emacs is obviously superior to whatever junk your team uses. To pair with you, they should all learn it. Now.
    20. Don’t rotate pairing partners - If pairing for two hours is good, then six weeks with the same person must be way better!
    21. Be arrogant – Seriously, what could you learn from that other guy? You know already: nothing.

      Which ones are your (un)favorites? And what ones are missing from this list?


      1. Daniel Lucraft:

        This kind of list needs numbers. I’m guilty of 11 and 12 for sure, probably 1.

      2. William Pietri:

        Great point, Daniel. Per your request, I have added numbers.

        One way to find out if you’re a keyboard hog is to get a chess clock. It worked wonders for me.

      3. Daniel Lucraft:

        I have a chess clock. :) But it ticks. Not sure I could handle the pressure.

      4. William Pietri:

        Heh. The one I used is digital, which helps a lot. Still, there was definitely a feeling of pressure at first. It was useful pressure, though. 10 minutes is a much shorter period of time when you have the keyboard. :-)

      5. Aman King:

        Hey, thanks for putting up that list. It’s so funny how you can identify yourself doing those things on occasion (hopefully rare ones). Plus, it’s a good list to share with those who’ve tried pairing for some time but are still trying to get used to it.

      6. Agile Pair Programming should be amended. | eval(code):

        [...] but the problem happens to good pairs when one of them had an ‘off day’, etc (see: 21 Ways to Hate Pair Programming). Another problem is accountability of ‘pairs’. If two people are working together on a [...]

      7. Ilja Preuß:

        A good remedy for 1 is a second keyboard. It takes a little getting used to, because you need a new protocol for switching drivers, but then it works just great.

      8. The Art of Pair Programming « The Art of Software Development:

        [...] don’t bother me. If you did give PP a try and failed to get good results, I must press you to check whether you did PP properly. If you think you did and still didn’t like PP, then please leave a comment explaining why. [...]

      9. aimee.mychores.co.uk:

        Really good list. I suffer from different mistakes depending who i’m pairing with.

        One of my worst habits is not on your list:

        Dictate to your pair. Because you are awesome and your partner is just a secretary to type your wonderful code for you!

      10. Andrew:

        Great list! Really good amplification. I’m guilty of 1 and 21. I think pair programming must start from this list.

      11. Retrospectiva de los coding dojos « El blog de Carlos Ble:

        [...] por pareja, donde el que tiene el teclado es uno, y el resto de la audiencia es el otro. Aquí hay una lista de 21 razones para odiar pair programming, más alguna otra que se comenta. Con esto quiere decir que no te [...]

      Clicky Web Analytics