I was reading my editorial from last Friday, and was immediately struck by a typographical error. I wrote, “…I thing…” instead of “…I think…”. When I publish editorials like that, it is really embarrassing. It looks like I don’t care; but I really do. So please accept my apology for this latest fault, and the many yet to come.
We also make the same kinds of mistakes when we are working with software. The difference, in most cases, is that when an error occurs, that application won’t compile. In other situations, we simply introduce a bug in the software, and sometimes they continue un-detected.
This reminded me of positive experiences I have had when writing software using pair programming. Not only does that practice provide a lot of other benefits, but it also helps for immediate syntax error resolution, but also helps prevent logical errors an individual may introduce. When working with set programming, like writing SQL, there is additional value in having two persons looking at the code. Sometimes it can be difficult to picture all the different nuances occurring in a single query.
There are few observations I have made about pair programming over the years.
Developers who have not used pair programming tend to be resistant to the practice. I am not sure why that is the case. But I have seen it occur in more than one occasion.
Pair programming is tiring. When you have two people focusing on the same problem, it is easier to stay focused. Email or instant messaging is put aside. Phone calls are allowed to go to voice mail. If done well, pair programming keeps both individuals engaged in the process, so you don’t have time for one or the other to have their thoughts wonder off. I have found that a couple hours of work this way produces great results. But, longer periods start to have diminishing returns.
Not everything we do lends itself to pair programming. If you are writing unit tests, pair programming can work nicely. Have the pair switch back and forth between writing tests and writing code. But, there is a lot of code we write that is simply scaffolding, or contains little or no knowledge. ORM code tends to fall into this category. We’re just doing plumbing with a different schema…the pattern is the same, etc.
Finally, there are things we just don’t see when we are working. I find that when I am coding, another person can see an issue with something I just did, whereas I may not see it until much later in the process. Intellisense has helped with this problem a lot.
Have you ever tried pair programming? Perhaps you may want to give it a try. I found two keyboards, two mice, and even two monitors make it a lot easier. Either person can take control more easily when you don’t have to pass input devices back and forth. Two monitors make it easier for both individuals to see clearly.
Have you ever done pair programming when writing SQL code? How about other languages? Perhaps you can share your experience in a comment?
Cheers ,
Ben