Pair Programming: Pros and Cons

    My computer science course at college has had us pair programming for labs in the first half of the semester. Pair programming is a technique in switch two programmers work on the same computer at the same time: however only one of them does the actual coding while the other checks each line of code as it is written. Every once in a while the two switch places and keep on coding. Over the past two months I’ve come to notice first hand some pros and cons, both from my own little team and the others in the class:


  1. Two points of view: When you’re stuck in particularly nasty patch of code, trying hard to work your way through, having a fresh point of view can come in very handy. However since both the programmers are side-by-side there has to be some care taken so that both aren’t always thinking the same thing.
  2. Silly mistakes are quickly caught: Simple mistakes such as syntax errors or repeated variable names can be easily caught and fixed right then and there. This might not seem like much, but it can cut down debug time later and prevent small irritating bugs.
  3.  Better concentration: This isn’t particularly scientific, but it seems to me that too people working have a lesser tendency to procrastinate or get distracted. This results in shorter development times too.
  4. Combining knowledge: Computer science is a vast field and my course is rather fast-paced. It’s hard for any single student to have a comprehensive knowledge of what’s been going on in class, so two of us working together means that we can pool our knowledge and work together. This has the added of benefited of learning ‘on the job’ and not having to dive into our textbook or go to the instructor every time we have a doubt.
  5. It’s a good training ground for large software projects: Very little software is written by one person nowadays, teams ranging from small to big are not just the standard, they are a necessity. Pair programming teaches you a lot of the soft skills you’ll need: tolerance, respect, understanding and responsibility.


  1. Skill disparity: This is the number one potential problem. If the partners are of completely different skill levels, you might have one programmer doing all the work or constantly tutoring the other. This is ok if you want to set up a teacher-student relationship or are introducing a new programmer to your system, but if not, it can defeat the entire purpose of pair-programming.
  2. Not actually getting the work done: Though I’ve personally experienced increased concentration when pair programming, for some people pair programming sessions can easily generate in socializing sessions. There are some people who don’t work when there is someone next to them examining their work, these people will not benefit much either.
  3.  Developer egos: This is something that is not likely to happen in a classroom setting, but in more experienced teams, each programmer might try to push their own ideas of how things should be done (both of which may be perfectly valid). These sort of conflicts can be downright disastrous.

So is it worth it? Some research suggests that it is, but there are enough variables to make the answer far from clear cut. If you can get a good partner who you’re comfortable with and can share similar work patterns, it might be very productive. On the other hand, avoid bad partners at all costs. However teamwork is a essential skill to learn, though you must be a competent programmer (or willing to learn) yourself before jumping onto a team. I think that you should try out pair programming every now and then if you can find appropriate partners. Using it in a classroom lab setting is also a good idea just as long as there are enough individual projects to make sure that one person isn’t doing all the work. But no matter what, it’s important to remember that pair programming is just another tool and will not compensate deficiencies such as incompetent programmers or poor working conditions and tools.

4 thoughts on “Pair Programming: Pros and Cons

  1. I have never been able to use pair-programming but would very much like to do. One company rejected it saying that one person wound up doing all the coding and the other watched. It seems to me that is a management error both at the pair level and the group level. The pair should detect that situation and the weaker of the two should often take the thinking part. The stronger should coax, but not instruct, encourage but not tell how. Get the weaker one to reach down deeper and get better. Flip back and forth frequently. Pairs should be mixed up occasionally. If the weaker of the pair stays weak, then maybe that person is either not ready for this level of programming or does not belong in this field.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s