Pair Programming continued

January 16th, 2010

In my previous post I talked about how I experience a really good pairing session, and in this post I like to discuss what I believe is needed for this to succeed.

Respect

As with any team activity you will need mutual respect for it to truly succeed. But with pair programming this needs to by lifted to a new level, just because of the very nature of developers and the intellectual type of work that they do. To much pride for your code is a bad thing.

We have all experienced the developer that gets personally offended when commenting on their code. This is a bad characteristic for a pair programmer because he will constantly be commented on his code. So respecting each other enough to know that the comments are never personal and are only made to improve the solution, or at least to discuss if it can improve. So you need to be _very_ open to learning new things as well.

Honesty

One of the things that I tend to do is always ask people what they think about a particular thing I have done, this can be code, a presentation or my cooking skills; anything really. The reason why I ask this is so I can improve myself, but the problem I encounter is that there are very few people that will tell you that something is not done properly. People are always happy to say; yeah that was good, or I liked it. But I don’t learn from that, and I am not so self centric that I believe I don’t make mistakes.

So next time some one asks you for your opinion, tell them the truth, hey if they don’t want to hear it they should not have asked. But seriously if you see your pair make a mistake or just know a more elegant way to solve the problem then you should say so. Not doing so is showing lack of respect to your college, you are basically denying him an opportunity to improve. And you deny yourself this opportunity as well, because you will notice that you will be wrong at least half of the times.

If you feel that you cannot be entirely honest with each other then you should discuss this.

Communication

A constant dialog is how pair programming should feel like, you are continuously discussing the small problems that you are solving. While keeping an eye on the larger problem space. You are not pairing to have someone tell you when you made a typo and things like that, you want to have a sparring partner to discuss what would be the best solution to solve the problem at hand. You cannot do this without talking about it, so talk, and talk a lot.

Nothing is more annoying than pairing with someone who just types, and where you have to guess by reading the code what goes on in his mind. If this is what you want then you don’t need to pair program. Just hope that the other party makes his code descriptive enough so you can read it. This btw is still a strong requirement for code written my a pair.

Experience

And here I mean experience in pair programming, this is not something that you will just pick-up and be good at, this is something that you will need to learn. And the only way that you get this experience is by doing it.

But it also helps a lot if you are pairing with someone that is similar experienced in programming as you are, but I don’t want to make this a very important thing as you know how the saying goes: “A single idiot can ask more questions then all the wise men in the world can answer”. What this means is that as a very experienced developer you can still learn form the fresh insides a junior has to offer you.

A junior might be less eager to ask for the keyboard, but by showing him the proper respect this should be an issue of the past fairly quickly.

Fun

Fun! Pair programming should be fun, not a burden. I know that in the beginning it can be uncomfortable, but this should be improving quit rapidly. If you keep feeling uncomfortable then you should try to figure out why this is, and if you conclude that this is something that just doesn’t work for you then perhaps you should not be doing it.

But there is no way you can make that decision after only one month continuously pair programming with different people.

Equipment

Good equipment like a dual screen or a very big single screen (30 inch or so), a proper desk that allows you to sit side by side. Perhaps even two keyboards connected to the same machine so you don’t actually have to move the keyboard over.

Without these simple things pair programming can be very annoying. Think about it, you are equally involved so you should have equal access to what you are doing. If every few seconds you have to move your chairs because the other person is having the keyboard and needs to correctly see the screen, then that won’t work.

Finally

Just to recap, the single most important thing that should be present is respect, all the other things will then be worked out in someway or another.

Happy Pair Programming everybody!

Mark Nijhof Craftsmanship, Pair Programming

  1. January 18th, 2010 at 11:18 | #1

    Hi Mark,

    You are right on target with this post. I agree, especially about the respect. Honesty is one that is often overlooked. In society today, we tend to not tell people when they are wrong, and that doesn’t help anyone. I think there is a tactful way to say “hmm, that might not be the best solution, what if you did this”, or “I like your idea, but I’m not sure I like your implementation, I’m wondering if there is another way we would solve this problem.” I have found where there is honesty and respect there is much growth.

  2. January 29th, 2010 at 10:32 | #2

    Hi Mark,

    Thanks for this ~ it was a great read!

    I especially like your point about making it fun… some people have a negative mindset and see pair programming as a way of forcing hard graft through partner accountability.

    Theses are the current best practices we use:
    http://www.knowledgegenes.com//home.aspx?kgid=10258

    Cheers,
    Ollie

Comments are closed.