DEV Community

Cover image for Let's chat about pair programming

Let's chat about pair programming

Justin Schoen on November 09, 2017

Originally posted on the OnShift engineering blog Hey, everyone. Today I’m going to interview Perry, a pair programmer practitioner. We'll talk ...
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 • Edited

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

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

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

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 • Edited

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 :)