Pair programming

When I was a couple years in my career as a software engineer, not long after finishing university, I got into a work setup where doing pair programming was for the first time possible. I remember this was something I wanted to get doing, because I felt I had a lot to learn from more experienced software developers, by sitting and working together with some of them.

So, I grabbed every chance I had to do more of pair programming, and the results were incredible, in my subjective assessment. I remember spending many days working with a colleague that was not too many years more experienced than me at the time, but that had worked on larger software systems longer than I had.

In particular, I remember us spending many hours in “debug” mode, going through a particular piece of code and trying to understand and come up with some fixes. And I remember having literally headaches at the end of a working day, which was a sign of the many successive hours of highly concentrated intellectual activity.

While for me the main benefit was clearly getting insights on the practical methods used by a more experienced developer, and learning from it, my colleague also benefited a lot from my concentrated attention and at least some of my ideas on how to proceed with the tasks we had at hand.

And all that came recently to mind again, because of a book I am currently reading about programming, which made me reflect back on my personal experience with pair programming.

One of the chapters in the mentioned book brings a lot of hard evidences, mostly based on published articles and studies, that point out to the fact that pair programming, together with formal code inspections, are the most effective methods to, among other positive things, reduce code defects. The evidence shows that they are actually much more efficient at that than other more “popular” alternatives, such as unit tests, regression and integration tests.

And that does not come as a surprise, based not only on my earlier experiences with pair programming, but also personal experiences later on with code review sessions, and overall assessment over code quality in different contexts, as I moved to work on many different systems, companies, and software products. With different job titles and responsibility levels.

At the end of the day, much of the quality in a software system reflects down to how single individuals do their daily work tasks, and pair programming is just a great tool to achieve more of what many people seem to look elsewhere for.