Cover image for What's your experience with pair programming?

What's your experience with pair programming?

madza profile image Madza ・1 min read

Devs who have done lots of pair programming, did you find this way more productive in general? What are some of the main advantages and pitfalls you experienced?


Editor guide

I don't do lots of pair programming, matter of fact I just did it twice when a co-worker didn't brought his laptop, it felt like having someone backseat developing.

To have the other person feel like being part of the process, I had to ask questions that I could otherwise just search in Google, things like that...

Needless to say, I don't like it, but I'd like to know how other people make it work.


Yup, that's why I asked it too πŸ˜‰
I imagine the scenario you described πŸ˜‰


If you are co-located, and working with someone who is working on the same thing you are, and you both practice reasonable personal hygiene, and you both have compatible ideas of how to go about developing software...

...that can work well. I've done it for two stretches, each stretch about a month long. It was enjoyable.

With the pandemic, and everyone on the team working-from-home, pair programming doesn't seem like a good fit for the situation.


I've always hated it. Don't kill productivity and the creative process (which at its core will always be individualistic, no matter how much the "team players" scream otherwise) by trying to combine mentoring with what amounts to bad live code reviews and "collaborative" micromanagement (just delegated to - or self-imposed by - other devs rather than managers themselves).

If it isn't clear, I have nothing but disdain and mockery for the terms in quotes above; at least in the ways they're so commonly misused/abused in toxic tech workplaces (also, "culture" usually equals "cult").


which at its core will always be individualistic

Can you expand on this?


Are you a bee or an ant? There is no such thing as a human hive mind, no "collective brain."

There is no such thing as a human hive mind, no "collective brain."

What about the internet?

There is accumulated knowledge, ideally in accessible repositories. That's completely different. Nobody expects every person to re-learn every human discovery from scratch.

The more actuate analogy is this: Unless you're live coding by choice, the internet isn't staring at your screen and following/critiquing your every move. And even if you are, it's going to be far from your most productive attempt at writing code.


Pairing has been my dominant style of development for the last 17 years or so, but I'll be the first to admit it's not for everyone.

  1. It's exhausting. The effort required to pair is going to naturally limit the number of hours you can code in a day compared to going solo.

  2. It's hard to get right. The balance between an effective pair and a pair where the navigator is completely passive is very hard to get. There will be a lot of social issues that you can typically ignore in a team that can come to the surface when pairing. For some teams, this might mean "X and Y should never pair" and/or "We should make sure X and Z don't pair too much".

  3. It's not always needed. The benefits of pairing don't always justify the cost in some occasions, although those number of occasions are probably less than many think.

I could construct a working environment where other practices (e.g., high and constant rotation of code ownership, lots of explicit knowledge sharing, mandatory code review on all production code, a lot more effort on up-front thinking and design before coding) compensate for a lot of the benefits of pairing, but I'd rather just pair where/when needed.


Thanks for the extensive insight πŸ™β€


I have done many pair programming in the past, I enjoy to work and learn from other developers on how to approach issues using different directions. The only con of this is that you need to get use to a different types of writing code. According to each person, that was way to be write clean a readable code.., so everyone was right on how they write code and that was some frustrating.
I never took for granted anybody as a competent developer, they were great but I could see how arrogant can "we" be as developers and that helps me to learn that we don't know everything and we still learning, even from beginners.


Did a lot of it, extremely beneficial, especially for Junior-Senior relation (Junior can catch up much faster), when introducing someone new to a project, or solutions that will stay with the company for years - you need more pairs of eyes before commiting to a way of doing it.


I made the career change to a dev position years ago. In my first job I pair programmed with a senior dev and learned so much. His productivity probably went down, but there were small things I was able to teach him. Or catch small defects that if I hadn't caught at the time would have caused a large time sink to track down.
Overall I'm the kind of person that does well when I have someone to bounce ideas off of, so pair programming starting out was a huge help.


I'd love to do it more, it's a great way to share information, learn and become better at getting feedback. Maybe the biggest blocker is the Impostor Syndrome: being worried the other person watching me work will find out I'm not a good coder and they'll judge me for it. A safe working environment might help.


I generally enjoy pair programming because it gives one an insight on how other people approach problems. It's especially beneficial in a senior-junior dev relationship, if the senior developer isn't condescending and the junior is a fast learner. Some junior devs might be intimidated by senior developers and view correction as being reprimanded for their mistakes, this comes when the senior dev is irritable. Generally for me it's a good experience and I've learnt a lot, especially on matters js. You have to find a partner you're comfortable working with.


My last team went through a cloud readiness dojo training. It focused on a lot of pair programming. Afterwards we would continue the same. It really helps you to get all the value of a code review in realtime and also allows you to help one another with ways to work faster. there aren't really a lot of opportunities to share your ways of better searching the codebase and find/replace with regex outside of pairing.


Never done it, but it sounds truly awful


I like it a lot for tasks, that are a bit more tricky. Banging out API design prototypes with a second pair of eyes is quite productive because you have a potential 'consumer' with you. After a while you can switch, change perspective and repeat the process. Debugging with a partner tends to be quite helpful as well. You are forced to 'externalize' your thoughts (speaking out loud to explain what you are doing) which often helps (me at least) to not trip over logical errors.

For common routine tasks I wouldn't use pair programming. Everything, that is routine doesn't really benefits from a second person. Super creative work (e.g. working on a really weird algorithm or other hacky thing) might also not be the best target as I usually don't have the capacity to vocalize my thoughts in this context. The results from this kind of work could (and maybe even should) be a good reason to get a colleague and evolve on the design.


I like it. We have a large code base and often there's domain knowledge that only one or two people have (not good but that's how it is) so it's easier to get on a call and chat about it and do some pairing instead of spending a few days trying to figure it out on my own.


I actually saw this yesterday, hahah πŸ˜ƒπŸ˜ƒ
Was working on fav list of YouTubers and this came up πŸ˜ƒπŸ˜ƒ


No experience yet, but I am really excited about it since I believe it will help me learn a lot


Don't like it
But can't do without it