WinstonYW

Now

I have been at Neo, formerly New Context, and formerly formerly Pivotal Labs Singapore, for 2 years now, and I do pair programming (PP) almost everyday.

When I don't, it's usually because of one of the following reasons:

• There's an odd number on the project team because someone is out for the day.
• I need to do research and evaluation of new technology.

But we really value PP on the whole, and we try as much as possible to pair.

Then

Two years ago, when I first learned that PP is part of Pivotal Labs's everyday culture, I was intrigued but, at the same time, worried. I wondered how it was like, and how I would like it.

I got a taste of it during the interviews and I came out of it unharmed but exhausted. Nevertheless, it was fun and I enjoyed it.

But I was apprehensive and I deliberated for a while if I will be able to do this EVERY DAY? I asked Google, and I was convinced by what I read from Sarah Mei's blog post, and I have not regretted my decision.

Why Pair Programming?

Because we see lots of benefits in doing it!

More than that, these are the usual reasons I would give when people ask me about PP:

• Focus
  • You will not do Facebook or Twitter. You will get things done!
  • You will not go down rabbit holes unnecessarily and focus on delivery.
• Knowledge Exchange
  • PP is especially efficient in bringing new hires up to speed.
  • PP is great for spreading technical knowledge amongst the experienced too.
• Collective Code Ownership
  • Anyone on the team can make code changes even when someone is away.
  • PP means bus factor != 1.
• High Code Quality
  • You always have someone to discuss alternative designs and solutions.
  • PP is code review on steriods and usually leads to better code and lesser bugs.
• Happiness
  • At the end of each day, you deliver and you feel a great sense of satisfaction.
  • At the end of each day, you deliver and your boss is happy.

Is Pair Programming For Everyone?

Given that PP has so many advantages, should everyone do it?

No. No. No.

The truth is, not everyone can be a pair programmer and not everyone will enjoy it.

There will be some engineers who are not suitable as a pair:

• The "Rock Star" feels you are slowing him down and he's uninterested in teaching.
• The "Researcher" just want to code in silo and get to the bottom of everything.
• The "Judge" will question you on every keystroke.
• The "Silencer" cannot code and talk at the same time. Not so fun..

In such cases, it's futile to try and force PP on the engineers.

However, it's then important to understand the benefits of PP and achieve all the above even without PP.

For Focus and Knowledge Exchange, those depend on individuals to make them happen. The organization can also help by having a prioritised backlog and structured stories to ensure that all engineers on the team are clear of their deliverables and datelines, and also have regular catchups amongst engineers to spread new technical knowledge.

To achieve Collective Code Ownership and Good Code Quality, the team can ensure that they have code review processes and tools in place:

• GitHub Pull Requests are great for code review.
• Barkeep can also help.

The boundaries are limitless and these are just some suggestions that I can think of.

Do The Good Stuff

Pair Programming is not a silver bullet but it definitely increases engineering productivity. On occasions when you can't do PP, you should still attempt to imitate the benefits of PP.

As a caution, NO teams should be transformed to do PP overnight, because PP is a skill that has to be learned and honed, and engineers should be hired to fit the PP culture.

I enjoy pair programming. It's fun.