Tuesday, June 03, 2008

Four benefits of Pair programming

Over the past year I have been able to practice pair programming as well as work on my own. Between the two methods, I definitely prefer pair programming. It has several benefits that I've been able to take advantage of, and that I think other developers will get a lot out of. The hardest part about pair programming is having a good teamwork mindset.

The four benefits are:

1. Stay focused more. I tend to get sidetracked when working, not just chasing down rabbit holes looking at pieces of code that I don't need to, but sometimes with things that are not even related to the current project. When I'm pairing, the other person won't let me get sidetracked in those situations.

2. Better design. Pair programming is the same as constant code review. Even when I know the right thing to do, I don't always see that what I'm programming would benefit from approaching it a different way. Having a second person sitting there giving opinions and even just asking questions, can cause me to think about the design of the code more and implement it better.

3. Better Quality. I won't say that there are no bugs. Runtime logic bugs still get through. However, combined with Unit testing there are fewer. But the more important aspect for quality is that words are sometimes a poor way to convey a message. The two of us may look at what needs to be done and understand it differently. This difference causes more conversation and better understanding with the client. It's not a chest beating for who was right, or more right, but an effort on the part of the team to make sure that the solution is right.

4. Better/Faster Learning. A huge benefit of pair programming is that a less experienced developer can pick up a lot of really good information. A competent developer can pick up new techniques and new languages in less than half the time if he is paired with someone who is good. This was a huge benefit for me. I practically learned Java in a month pairing with a good programmer.

No comments: