Originally posted on the OnShift engineering blog
Hey, everyone. Today I’m going to interview Perry, a pair programmer practitioner. We'll talk ...
For further actions, you may consider blocking this person and/or reporting abuse
In my experience, benefits of pair programming:
I'm sure there are more, but that is the ones that have struck me as "wow"!
Point for point
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!
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!
I agree with all the points! What is your opinion on experience difference between pairs? If you think of multiple permutations with this parameter.
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.
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.
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?
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.
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...
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.
really like this style of article :)