I think I do it terribly when I pair with someone. It doesn't feel natural, far from it, sometimes even feels tortured. But it still works wonders..

1. You stay focused

2. Often it turns out that me and my pairing partner are out of sync on either what should be done or how it should be done. And in those cases, often, the truth (for the lack of better term) is in the middle.

3. Doing quality peer code reviews is hard and takes discipline. If you lack it, pair programming is a good shortcut.

4. You get immediately two people owning (or, rather, invested into) the thing. So the effort is less likely to lose steam.

I'm not denying though that there probably are other ways of interaction (async or not) that may still bring these benefits.

EDIT: more things.

5. Having someone in peer code review question what you have been busy with in the last couple of days hits harder, compared to when someone filtering out what you put in the code as you explain your ideas.

6. Bonding.

To add just one thing to this (which covers most bases I think), it really depends who you're pairing with.

I've had really great times with a buddy at work, paired up, complementing eachother's skillsets, getting things done, and having a great day at work.

And I've worked with far less agreeable personalities who're always right about everything, in your face, and just plain not enjoyable to be around for any extended period of time.

That's probably the biggest takeaway from pair programming for me. With someone good? Have a wonderful time accomplishing a lot. With someone bad? Have a stressful time... maybe accomplish something.

For me:

7: Learning. I never learned - or taught - as much about programming as when I was pairing. Everyone has their clever little tricks they've come up with, and spreading them around as problems come up is wonderful.

Another benefit is establishing team norms and best practices, which is also a goal of code review, but pairing accomplishes it in a bottom up way rather than a heavy top down way. I've worked on teams where review was a very important part of our process and it was common for code to be under review for days or even longer.

I wrote a guide for newer pair programmers. People have said they found it helpful, so maybe you will too!

"Your First Pairing Session" – https://tuple.app/pair-programming-guide/your-first-pairing-...

Pair programming is great, but it's a skill you need to learn, so it's best to pick it up from pairing with experienced pair programmers.

If you just put two normal programmers in front of a computer with a programming task, you're more likely to end up with two annoyed people than great teamwork and code. At least at first.

The day you convince me I can get more productivity out of two programmers programming together than two programmers programming separately is the day I’ll consider pair programming.

I’ve been in this industry for 40 years. It hasn’t happened yet.

I think the idea is that by writing less buggy code with two people you save in refactoring, bug squashing, and fire management down the road.

Similar to testing I suppose.

No idea how the math works out in the end, I assume it'd be highly variable based on the product being built and the people involved.

What little pair programming experience I have makes me think it’s great to do now and then, but maybe not all day every day. You get to know your team members, share skills, see different perspectives and ways of approaching a problem, and understand how your way of working will affect others ability to do their work. Do it once a week or so and I’m confident it will be good for the quality of the code and the team.

I have found that pairing works well for teaching and for solving particularly tricky problems. It also results in higher quality code than working individually with reviews afterwards. However, it is a fair bit slower than working individually - depending on the type of work 0.5x - 1.5x a single dev. That said, the outputs are of a quality actually unachievable with a single dev, so comparing time doesn't always make sense.

So, like many things, it is a tool that should be used when you feel it helps. For example, API design can be done well in pairs, where the code quality has a big impact later on, and then the functionality implemented individually. It also is a great tool to speed up your onboarding process and get new devs giving useful feedback from day 1 and being highly productive within a week or 2.

My last team lead an I thought and spoke at about the same rate, which made our pairprogramming exp. Tremendously useful bc see had institutional infrastructure knowledge, and i held intimate product knowledge.

With out powers combined it saved about a half work day once a week easy.

Ymmv but i feel pair programming is a function of individual knowledge base and communication

I'd say pair programming always starts organically at my current workplace (well, it's certainly never really planned; mostly it starts with "pair debugging"). And I have to say: Given the right partner for the task, I usually really like the experience.

For me, a big part of this is that rubber ducking seems to really work well for me as well as some of my coworkers, but although I actually have a duck at my desk (more of a gag), I could never actually use it -- in an open space office, I just can't help but feel like an idiot while discussing the codebase with a toy ;-)

Of course, a big upside to a coworker playing the duck part (aside from them not being as stoic and giving me valuable feedback) is that this practice automatically familiarizes more people with a given piece of code, which is also never a bad idea.

Pair programming reminds me of a sweatshop type of situation, when there is no time to reflect for too long just produce code so that your pair won't tell your boss that you are stupid. Code driven by fear is never good. Okay, you might have a pair that you feel comfortable with and tackling the task at hand goes easy. But in that case again, probably you didn't have time to think when you couldn't get something right and your pair gave you solution instantly. This way your learning is screwed and of course you got the output, but this has done little to better yourself. Pair is fine to get to know someone, perhaps show new person a project and do a simple task with them, but other than that it is a waste of time. Basically two developers solve one task whereas they could solve two and also learn more.

I interviewed for a week at a consultancy known for pair-programming a long time ago.

Each workstation had two chairs, a large iMac in the middle, and the developers had an individual macbook/kb/mouse on each side.

The code was on the middle machine, and either kb/mouse could control it. They also were using software named Teleport(?) that let you seamlessly interact with both the main iMac and your own laptop. I don't remember exactly what it did, maybe let you drag files between the two computers or something.

I got to pair-program with them on assorted real world tasks that week, a different employee each day. I was generally impressed with the workflow. There was basically zero downtime in terms of progress. I can easily them imagining at least getting a 2x productivity boost, but I'd imagine it was more like 2.5x or more.

Sheepishly, what I didn't like about it was that I'm the kind of person that likes to get a lot done and then work on my own stuff on the job, or have the freedom to surf HN when I'm ahead of schedule, and that was kind of impossible there without your teammate knowing it. :)

But I will say it was very stimulating and fun. The other developers were really nice and fun to talk to. I work remotely, but I would certainly consider that arrangement if I were to get a desk job again.

It's better than the sort of office job where you're languishing on your own and nobody has a firm grasp of what exactly you're even working on in precise terms. I've been there before and it's incredibly stressful when you fall behind pace and your work performance starts to suffer. I feel like pair-programming eliminates that kind of thing.

2x productivity boost compared to one programmer or two programmers ..?

I have a hard time seeing why this would work. On the other hand, it's more or less a hand over of knowledge for the system, so in that sense all the negative effects are might be zeroed. I've got this feeling that knowledge hand over is the biggest problem in the industry.

I would really hate to have to do pair programming but I'm not totally convinced it's all bad for the company/product. Maybe one day a week to spread the knowledge?

EDIT: The song is nice. A bit to specific topic to be funny though.

This interview story sounds more like Hashrocket (the consultancy I founded in 2007) than Pivotal. Pair programming used to be a big selling point for us both with hires and clients.

Yeah, the focus and the full 8 hour work days is one of the attractions of it.

I did it for two years. I found that it was draining to be focused the full time every day. I liked the way it worked, I loved the code quality that came out of it, but I can't do it 8 hours a day month after month.

I was exhausted the first month, but... I actually hate myself when I slack off. I love few things more than getting things done, and pairing provides me with that euphoria and discipline.

I do fully understand that it's not for everyone!

Let me guess... Pivotal?