Pushing forward with the Autonomous Craftsmanship Core series. This week on our plate: How can you force pairing down the throat of your team even if they’re not really into it?

I’ve already touched on this subject a few times before, especially since it’s one I find really important and had to handle a few times before. Pair programming feels to me like the best technique currently known to the software industry for making a team highly productive and have global code ownership. It’s one of those things that didn’t click right away when reading Extreme Programming Explained, but man did I get it wrong.

I’ve loved pairing from the moment I started doing it and ever since I find it hard doing hard work without a pair by my side. The problem is that most of the software shops around are still not pairing regularly, making it hard for a pairing junky like me to have fun.

So, how can we stop bitching about our team not pairing and actually get shit done with a pair? As opposed to the previous posts on the Autonomous Craftsmanship Core, this is not something one can do alone, and so is a bit harder to work around.

Basically, not calling it pair programming. It might be a bit tricky socially, but it’s worth it. Some real examples:

Can you help me out?

If I have a short task (ideally – no more than 30-45 minutes) that I want some help with, I just find someone on my team and ask for some help. Hopefully, you’re not in a team where asking for help sounds problematic. Then, once you’re both on your computer and working on the problem – you’re pairing. That was easy, wasn’t it? Do it enough times (without looking like an idiot that always needs help) and your mates get acquainted to the idea fast.

Volunteer to help people

I love walking around the team and seeing what people are doing. Every once in a while, simply walking by someone and asking how are things going might trigger a “Take a look at this” response, and you can help a fellow coder get unstuck. I used to do this even outside of my team. Spending 15 minutes with someone to help him solve a problem and share some knowledge and technique in the meantime is just awesome.

Review code to be in the loop

I try and read most of the commits being done to projects I’m involved with. It has many advantages, and one of them is that I’m familiar with most of what’s going on around me. That means I might find little problems, ideas and changes that might help my team. I then just go to the person that made the changes and share my ideas. Sometimes that would drag us both into a short pairing session.

These are basic techniques that I’ve found helpful several times. Even people that have never heard about pairing start liking it (if they really find you helpful and not annoying, of course). I just love seeing how after a few weeks, people come and ask for help if you’re not around, and how slowly the idea of doing some tasks together becomes obvious. I don’t have to have them call it pairing, and it doesn’t have to be 100% of the time. The bottom line is that good practices stick, even unconsciously.

You should subscribe to my feed or follow me on twitter!