Pair programming doesn't suck

I just read an article outlining why pair programming apparently "sucks"

Go read it, come back. I'll wait.

The author also lists some positives, which I totally agree with:

• improved communication skills
• improved dev skills by pairing with an experienced programmer

But the list of "negatives", well, those aren't the fault of pair programming. Rather, they're people problems. But we can work around those, and we should anyway, even if not pairing, for reasons which should become apparent:

I hate typing on someone else's computer or when someone types on my computer

This is based in a legitimate concern: I try to keep my station relatively "non-icky", but I've worked with people who seem to be trying to store food for the winter season in between their keys or on their mice.

Whilst we should all probably try to keep our workstations neat and tidy for our own health benefits (physical and mental!) we naturally will have differing levels of fastidiousness around this area of our lives. Some people are neater than others. Some people are simply less aware of how they're transferring lunch into the keyboard vault.

There's an easy solution to this. No, it's not "cleaning your keyboard every morning" (though there's nothing wrong with doing so). Some people are never going to be satisfied with the level of cleaning that can be attained. Also, sometimes, it's just not practical to do a full clean every day. I want a clean keyboard, but I have to make the compromise that it's "clean enough" for me, until I get some time to pull off the keycaps and clean properly.

The easy solution is: get another set of input devices. Another keyboard. Another mouse. Done. The cost isn't that high -- you don't need top-of-the-line gear here, as it's likely that when you're choosing to pair, the person whose workstation you're at will do most of the driving, but the guest should be able to work along at any point.

Yes, this means that you're going to sit at someone's machine and they won't have your favorite Cherry Red MX keys or your fancy Razor mouse. As Ewan McGregor says: "have a teaspoon of cement and harden up a bit".

If you use editor plugins like Vi-mode, be aware that many people don't know how to use Vi. Learn how to toggle that plugin on and off quickly, and do so before your partner tries to type.

Constant breaks

This is a point on which you and your pairing partner should decide together. Some people need to break down their day into smaller chunks. Some people can go a little longer. I can tell you that for the health of your eyes, you should find a way to look into the distance every 20-30 minutes, and you're probably dehydrated and don't know it.

So it's reasonable to say that on about every 40 minutes, it's ok to stand up, stretch legs, get a glass of water or a coffee, get back to it. But this is still something that's up to the pair, and not to be enforced by some arbitrary rules. The author may have experienced some kind of structured timing because of the environment, a coding bootcamp,, but who still works exactly like they did at school? Anyone?

Egotistical partners

This is at the heart of a lot of pairing issues: ego.

I can't say this enough: if you want to be successful in life, you're going to need to learn how to drop the ego, especially if you want to work with other people at any point in your career, and if you don't have billions of dollars to buy the allegiance of people around your or some cult-like following that puts up with your BS because they think that you have some kind of super-powers that entitle you to be a general jackass. I'm thinking of a specific famous person, now deceased, but the personality isn't exactly unique.

Even if you're not going to pair program, you need to understand that you will be wrong at some point. Particularly when you're learning, whether that's domain or tech, the path to mastery lies through multiple failures. You need to be able to listen to the ideas of others. You need to be able to concede when you're wrong. You need to be able to find compromise when it doesn't matter who is actually right because there are many ways to solve a problem.

Ego is your enemy. Pair programming will simply put a giant spotlight on your ego if it's toxic. Pair programming may also enable you to learn how to drop that ego, if you pay a little attention to how you're feeling. Getting mad because someone is questioning your solution? Perhaps that's ego. Getting mad because someone reminds you that you're not following the accepted style guidelines, or you've started writing prod code without tests, when the agreement is to use TDD? That's your ego, popping up again.

That same monster will pop up in code review. If you don't learn how to master it, pair programming is likely to be only one of your problems.

Passive partners

Ok, this I struggle with, because I don't see the point in doing half a job.

Just like with ego, this is a problem you need to sort out with yourself, especially if you're about to work collaboratively with someone else. Again, the setting doesn't have to be pair programming -- we all roll our eyes at the person in school who wouldn't work on the group project, just as much as the team member who doesn't pull their weight. Pair programming will just highlight these people.

If you can't talk to them directly (something like "hey, want to help a bit here?") then the only recourse is to talk to your team leader. I can guarantee that the person paying their salary cares.

Take a close look at yourself: are you pulling your weight in your team? Are you perhaps the person people dread to work with because they know they'll have to do the work themselves? Or simply have to fix up all the things you did half-assed? I'm not talking about making mistakes -- that's going to happen. I'm talking about people who just don't care to try harder.

You can do better.

Micro-managers

Micro-managers are control freaks, plain and simple. This is closely tied to ego -- if you can't accept that there are multiple ways to get something done, if you can't let people work with some level of trust, then you are trying to control everything around you.

Stop. Think a while how it would be to work alongside yourself! Yes, your pair partner may have missed a semi-colon. Don't you think they feel embarrassed with the compile fails? We all make mistakes, and part of pair programming is helping to pick up each other's mistakes, but if you're hovering all the time, it really ratchets up the tension in the dynamic.

Remember, you're both here to solve the problem. You're both here to tackle the puzzle. The other person is on your team.

Noise

This can be a legitimate concern, but again, can be solved by moving people into their own spaces. This is not the fault of pair programming, per se, but large-scale pair programming will certainly highlight bad office layout. I know it did at my former job. We used to pair a lot and there were also some poor people trying to participate in remote team meetings whilst others were fully-engaged in collaborative efforts.

Some tips though: be aware of your volume. One of my favorite people is known universally for being really loud. He's not often aware that he's being loud. He doesn't do it on purpose: he's just a more expressive, extroverted kind of person. He's also a teddy-bear, so whenever I reminded him to lower the volume, he always happily obliged.

People can make some of the change here, but the real solution is to stop packing your developers into one open-plan room. If your company won't change this, leave -- trust me, it will be worth it. Cramming devs into tight spaces is indicative of how the company values those people. If you're squeezed in like a sardine, unable to move your chair without hitting someone else, chances are good you're seen as a "resource", not a creative person. Bring it up with management, and if nothing changes, leave as fast as you can.

Wrapping up

Pair programming can be awesome if you:

• provide spare input devices (mouse and keyboard)
• leave the ego at the door
• engage with the problem and your pair partner
• don't be a nag - let people make their own micro-mistakes, and be there to catch the big ones
• find ways to isolate your noise from others