Experiencing pair programming

At Luxoft Canada, working in a team of four developers we were able to pair and work on specific tasks that were taken from the Scrum task board.

Physical aspect of pairing involved having two developers (navigator and driver) sitting behind a computer connected to two sets of keyboard and mice. We managed to change our desks to rectangular desks to easily accommodate two programmers working behind the same desk.

When we began pair programming, some participants had no or little desire to participate. The only way to overcome this lack of desire was to experimentally try pair programming. I tried it and gradually grew into it and started seeing its tremendous benefits to the organization and us.

While working in a pair, there were cases in which we could not accept the other person’s point of view about solving a problem. For example, in one case I insisted that we needed to add more unit tests for a problem and my partner was insisting that what we have written was enough. We spent a few minutes explaining our positions and finally I had to compromise by not introducing the new unit test and leaving the decision to be made at a later time.

I paired with two people multiple times. On a few occasions the navigator programmer felt more skilled than the driver in performing some actions (as simple as using short keys) or the navigator was feeling s/he knows the area of the application better than the driver programmer. In these cases even though the navigator explained the techniques to the driver, it took a while for the driver to pick up the techniques and get used to using them. The navigator who had explained the tricks to the driver and still was seeing the driver using the old techniques felt frustrated. We learned that the navigator should explain the techniques and allow the driver to pick them gradually over time.

In other cases where we had some bad programming habits that pair programming surfaced them and gave us a chance to change them.

There were a couple of cases in which the driver would not give the navigator a chance to code. After a short period of time we all felt that this makes the navigator feel marginalized and lose his focus on the task. As soon as this problem was recognized, we made sure to switch the roles often.

In some cases in the driver seat, I was finding it difficult to explain what I meant when proposing a specific solution. I found it easier to take a minute to write the piece of code and show it my pair. Once, it involved modifying the code my pair had written a few minutes ago. It was good that he did not mind me touching his code and he was patient enough to let me take my time to explain what I meant using written code. I think the navigator should trust the driver and let him to take his/her time to explain his/her point either verbally or in written code.

I believe some of us occasionally create negative images of ourselves when we feel we are not functioning our best and start expressing the feeling verbally. I have done this and heard others doing the same. This usually does not have good outcomes. I have seen that expressing the frustration and creating negative images make things worse and affects the outcome of pair programming.

We made sure to have a few minutes of informal retrospective about pair programming experience among ourselves. This was done at the end of the day or when a task was completed. The talk about our achievements, what we really did well and what could be improved, educated us to do better each time.

For us:

1. Pair programming is an extremely efficient way to do general technical and application knowledge transfer.
2. Promotes team communication.
3. Results in better design.
4. Helps eliminating buggy code early or not introducing it in first place.
5. Increases team productivity since the team members will have undivided attention during coding.
6. Improves communication and collaboration skills of the team members.
7. Makes work more fun.