Is pair programming effective?

To those new to the term, pair programming is a technique of software development in which 2 people share 1 computer and only 1 person at a time gets to control the keyboard and code. What does the other person do? Well, similar to a rally car race, the other person (or navigator) monitors the state of the program.

What do I mean by state? Well. Pretty much everything except for the code. The logic, the architecture, and even the upcoming elements that you have not gotten to just yet.

While not commonly seen much in the corporate world, I have spent more than a few days of my coding career in these situations and I can say that I am huge fan, given the ideal conditions. Because not every project or situation can benefit from a 1 shared computer environment. And in the wrong environment, it can probably hurt more than help.

The following is an example of when pair programming can be a massive help as a productivity hack.

The first time that I used pair programming in an approved corporate environment was completely by accident due to a malfunctioning PC. The solution, due to incredibly short deadlines, was to hop on the PC of the person next to me and continue working. That person just so happened to not have much work that week, and so for the first day they essentially just watched me code for 12 hours straight.

By the second day, as I broke down the project to them to break through the awkwardness of having stolen their PC temporarily, they were pretty much caught up to date. From that moment on, they became my eyes and ears and guided my steps carefully. To the point where they officially got added to the project, joined the meetings, and so on.

Now to why this was beneficial. This particular project was very difficult. There were multiple databases, multiple API's, offline/online cache storing, UI/UX rebuilding based on state, etc. It was also a brand new project with no legacy code or concept to rely on.

These type of projects tend to be the most troublesome, due to specifications being incomplete or miscommunication among teams. And this is why having a navigator right next to me the whole time was such a huge asset. Because they caught things immediately from the start before they became huge headaches later down in the development life cycle.

At some point during the project as the other person became more comfortable with the code, we were able to switch roles. This is something that might have happened several times per day, depending on the work being done. It kept the work interesting on both ends and more importantly, it reduced the overall time in which code was not getting written.

So is it effective? Yes, depending on the complexity of the project. The more complicated, the more effective.