loading...
Cover image for Let's chat about pair programming

Let's chat about pair programming

j23schoen profile image Justin Schoen ・5 min read

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.


Discussion

pic
Editor guide
Collapse
eljayadobe profile image
Eljay-Adobe

In my experience, benefits of pair programming:

  • continuous, on-going code review (and a deep code review, rather than a shallow one that typically happens with after-the-fact code reviews)
  • if doing bona fide TDD, then pair programming will keep them honest
  • code quality improves a lot
  • best possible knowledge transfer between the two programmers and/or mentoring
  • incredible team building and cohesion (especially if pairing promiscuously amongst team members)

I'm sure there are more, but that is the ones that have struck me as "wow"!

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

Point for point

  • A paired programmer can be totally disinterested, there's no guarantee of deep review. A person reviewing a PR on their own can be highly interested and provide a deep review.
  • "keeping them honest" sounds a like a horrible reason to pair up. It's like you don't trust the programmers to do a good job. Missing test, and lack of TDD can be easily spotted in PR reviews.
  • There's no evidence that code quality improves
  • Mentoring is different than pair programming, I support mentoring. As to other knoweldge transfer, sure, pair programming should improve shared knowledge on a project.
  • This sounds as though the team would be completely isolated if it weren't for pair programming. Non-pairing teams should still talk with one another, bounce ideas around, and work as a team.
Collapse
eljayadobe profile image
Eljay-Adobe

None of those counterpoints were what I had experienced doing paired programming. All my points are anecdotal of my experience.

Your mileage may vary, of course.

Aside: I've tried my hand at making a general purpose programming language. It's hard. (And fun. And frustrating. And rewarding. And educational.) Best of luck with Leaf!

Collapse
j23schoen profile image
Justin Schoen Author

I agree with all of these! I've had nearly identical experiences with pairing. The code quality is a big one for me. It's easy to write code that you can understand because it was in your brain, but having a pair enforces that it's written cleanly and understandably. Happy pairing!

Collapse
divyenduz profile image
Divyendu Singh

I agree with all the points! What is your opinion on experience difference between pairs? If you think of multiple permutations with this parameter.

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

I'll linkg to my standard response of Why I'm not a fan of pair programming. I'm a big fan of working together on problems, and even pairing as necessary, but against this kind of dogmatic idea of always being paired.

Collapse
j23schoen profile image
Justin Schoen Author

Thanks for the comment. Pairing isn't for everybody, which it seems is the point you're conveying in your article and I agree with that. As developers we have habits and ways we like things to be done, and that's fine. Pair programming is something to try and will likely push you out of your comfort zone, and you might even learn something new.

Collapse
ozzyogkush profile image
Derek Rosenzweig

Got any tips for pair programming when not in the same physical space? IE one or both are working remotely? I know we can use video conferencing software and some of those allow for one person to take over the mouse/keyboard of someone sharing their screen, but beyond that?

Collapse
j23schoen profile image
Justin Schoen Author

Thanks for reading!

Hmm... I haven't had experience with it so I can't offer up much advice. What I will say is that you need to keep communication sharp and keep each other engaged. I imagine it would be easy to let your mind wander and get distracted if you aren't the one typing. I think it would benefit both of you if you talk out your plan and design before writing any code so you both know the direction to take. I hope this helps! Good luck.

Collapse
andydangerous profile image
Andy

There are a whole bunch of good recommendations on remote work and pairing here: remotelysoftware.com

My personal preference is to use tmux/vim and a video chat. If you're not into that tooling, I just learned about a cool-sounding tool for Atom. blog.atom.io/2017/11/15/code-toget...

Collapse
purplebooth profile image
Billie

My experience is that pair programming (believe it or not) depends on the pairing.

  • Pair two people with conflicting approaches to a problem, and you get conflict.

  • There is no longer an explicit "code review" step. It's expected to be constant, but this is not always the case. Lack of an explicit step means that the dynamic of the pair determines if they will sit down an review the code afterwards.

  • It's tiring. There is a reason pairing guides encourage frequent switching, it's thats to force breaks. You need way more breaks pairing than you do solo.

So yes, you get two people together who're relatively comfortable with each other and know good design and practices they will produce higher than quality code with a great focus and lower than normal bugs, and the bus factor thing is great.

The question really is, is your team comfortable enough to work like this, or big enough to rotate before friction can get really bad.

Pairing has big benefits, but it can be hard on your teams mental health.

Collapse
karfau profile image
Christian Bewernitz

really like this style of article :)