Let's chat about pair programming

Originally posted on the OnShift engineering blog

Hey, everyone. Today I’m going to interview Perry, a pair programmer practitioner. We'll talk about pair programming, his experiences, and he’ll give us some tips on pairing effectively.

So, Perry, tell me, why should anyone consider pair programming?

Great question, you’ve earned a Schrute Buck for your curiosity. Currency aside, there are a number of reasons you should pair program, and we can get into those, but I think a big reason is having the ability to bounce ideas off someone else as you code your solution. Here's a common scenario: You're working on a problem when you hit a wall and need to ask a fellow developer for help. When you start explaining the problem to them the solution comes to you in a flash of brilliance! This concept is not new; it’s called rubber-duck programming, which is when you explain your code line by line to a rubber duck with intentions of discovering bugs and confusing logic, or getting unstuck, just by talking about your code out loud. I'm not trying to say that you should only be pair programming so that you don't get stuck, but pairing provides you with a continuous feedback loop and can reduce or eliminate those frustrating moments when you get stuck.

Interesting. So what do you recommend pair programming on, like what kind of work?

I encourage you to try pairing on a full story or card or bug fix or whatever you call it at, where do you work again?

OnShift.

Right! As I was saying, it’s important that you pair on something beginning to end if possible. I think that’s where you get the most benefit out of it.

What kind of benefits we talking about?

Code quality for starters! You look like you’ve written some terrible code on your own before, so I’m sure...

Watch it, Perry, though you aren’t wrong

I’m sure you’ve gone through the process of writing a bunch of code, opening a pull request, and then having to either explain your code to your team or having to do a lot of refactoring.

Go on..

Pairing can help with these issues. When you pair, you always have someone next to you to bounce ideas off of, share in writing the code, make collaborative design decisions, continuous code review..the list goes on. You can’t just Wild West it because the developer you are pairing with holds you accountable and vice versa.

Sometimes I wear a cowboy hat when I code

That’s kind of dope actually.

Thank you. What makes for an effective pair?

First thing is for each pairer... is that a word? I’m goin’ with it... to check their ego at the door. Pairing is not the time to get all high and mighty, nor is it the time to feel like your skills aren’t good enough. Pairing is a collaborative process and you’re going to find areas that you and your pair are both weak in, but you need to roll with it and learn as much as you can as you go. Be open minded and don’t take it personally that they’re a VIM master while you can’t figure out how to close the editor. You also don’t want to hold anything back. What I mean is that if you have an idea, just start typing, explaining yourself as you type. Maybe it’s not right, but it may spark something in your pair’s head and lead to a solution.

That’s easy, especially for me because I’m wicked smart.

That’s the spirit. I also place a lot of value on the conversations between you and your pair. The exchanges are what make pairing so valuable. This goes back to what I first talked about regarding self-explanations and rubber duck programming. Pairing allows you to continuously get feedback, potentially triggering those ‘ah-ha’ moments more frequently. Instead of working solo and making decisions on your own you can benefit from having another engineer right next to you to collaborate on code design.

This leads me to a few items I forgot to mention, which are effortless knowledge transfer and additional code comprehension. When you pair with someone you’ll inevitably learn things from each other. Now these can be small things like keyboard shortcuts or useful built-in functions of a language, but there is also a high likelihood of learning about a section of code you haven’t had experience with before.

As far as code comprehension goes, pairing results in two people having a clear understanding of the code that was just written as opposed to the usual one person. This is more of a long-term gain because there is always the possibility that the person that worked on the code will not be available to help explain things, so having an additional person with that same knowledge could pay off big down the road.

Alright, Perry, you seem to really advocate pair programming. Are there any cons to pairing?

There definitely are, though I think the good outweigh the bad by a long shot.

Pairing forces you to sit next to someone and interact, and some days you don’t want to; you’d much rather fly solo at your desk with your headphones on, which is totally fine, but the forced interaction can be seen as a drawback.

The possibility is always there that you’ll butt heads with your pair, which isn’t fun for anybody. However, I think this offers a chance to improve interpersonal skills as you’ll learn to compromise and communicate more effectively.

One last negative I’ll note is that some believe pairing reduces your team’s velocity. This isn’t something I agree with. I believe pairing pays short term and long term dividends with all of the pros I talked about before.

That’s something that came to my mind right away: ‘I have to sit and talk to somebody all day?!’ Doesn’t sound so fun to me.

Right, and there is nothing wrong with asking your pair if it’s cool to fly solo for the day. We’re all developers and want to just code by ourselves sometimes.

Do you have any final tips for someone that hasn’t paired before but would like to start?

Create a comfortable environment for each of you. I recommend you each have your own keyboard for starters, as well as an external monitor or two. Just avoid using only your laptop.

It’s important that both of you are engaged in the problem or solution. If you feel like you’ve been spinning your wheels for a while then recommend to your pair that you get up and take a break and come back fresh. Ask your pair questions about what they’re writing or thinking about the problem. Try to avoid long silent stretches where one person is typing while the other is just watching as that’s defeating the whole point of pairing.

Pairing takes practice, just like any other skill, so don’t be discouraged if it doesn’t go super smooth the first time, or even the first few times you try it. You’ll probably find that you pair better with certain devs, and there’s nothing wrong with that.

Great advice, Perry. I’m looking forward to pairing for the first time and showing my pair how much better I am than they are!

Wait no, I think you missed the poi-

Thanks for coming, Perry.