Several times I programmed in pair and I want to share my experience with it. What are the main benefits of pair programming?
- The code is of better quality, because there is always the other person watching over your shoulder and seeing what you have overlooked. Wikipedia says that defect rates are about 15% to 50% lower.
- There is a synergy of ideas. When you work on your own, you might get stuck easily. This rarely happens when working in pair. When you don’t know how to do something, the other probably knows it. Or you start talking about it and one idea leads to another, and soon enough you will come up with a solution.
- Increased team morale. By working closely with someone, you get to know him. And you share responsibility. The code is no longer yours, it belongs to both of you.
- Learning from each other. Chances are that each of you is more experienced in some area than the other one. By working together on a problem, you share that knowleadge. There is always something you can learn from your colleague. Be it high usage of keyboard shortcuts to increase productivity, or different way of thinking, better coding techniques, different set of tools.
- Maintaining focus. When you work with someone you just can’t browse the internet or pretend that you are working 🙂 There is always something happening, either on the screen or between you when you talk about the problem at hand. It naturally helps you to maintain focus.
- Time management. Set alarm clock to 20 minutes and then change places. 20-25 minutes is recommended time to maintain concentration. (But of course you don’t have to work in pair to use it.) See Pomodoro technique for more info.
These were the main positive points. What is the downside?
- Pair programming is noisy. Unless you decide not to talk (I have never tried that), there is no way how to avoid being noisy, which might be distracting for your colleagues. It’s also easy to get excited over some idea or to get into a kind of friendly argument (which is OK 🙂 )
- It might be more exhausting, simply because there is more things to pay attention to. Beside your usual IDE there is that other person. He talks, he takes “your” keyboard, he disturbs you by pointing out possible future bugs. He will almost certainly spot weak points in your code. And you might start rather a heated discussion quite easily.
- Less code. But that might is actually a good thing :). Quality of software doesn’t count in lines of code, does it?
- Sometimes you get stuck when working in pair too. Then two people are stuck instead of one. But it is not very often and usually for significantly shorter time then when the both of you work individually.
That’s NOT the reason I *really* hated it, though. The reason I hated it is because – are you ready for this? – I might be wrong. Yes, there is a slim chance I could be wrong – dead wrong, stupid wrong, or better yet, absolutely completely “WTF were you thinking of implementing it this way you dumbass!” wrong – and my pair would find it and point it out to me. In other words, I was afraid of being naked.
The fear was being critiqued. But then I did it. And sure enough, I may – MAY – have done a few things in a less efficient manner. But something amazing happened – I learned. I learned a lot faster with someone at my side than I could ever have learned alone or during/after a formal code review. My pair helped me organize my thoughts – and funny enough, I helped my pair as well. My pair helped me get up to speed QUICKLY on the new system being developed. Faster than I could ever have done it alone.
I learned new development techniques that have stuck with me, even today. Things I’m not sure I could have learned on my own.
It’s not practise what makes perfect. It’s perfect practise. I believe that pair programming fits into the perfect practise category. It helps me to write better code.