>Honest question here, is pair programming still a thing?

Yes. Whether remote or in person, pairing works best when there's a experience/skill mismatch. Both parties benefit because the senior has to know and explain the why and the junior learns the what. I enjoy it as long as it's small doses.

It is draining and tiresome when done for long periods but I think worth it. It keeps you sharp and builds relationships with teammates.

Pairing with someone on your level can also be beneficial but with diminished returns.

> Remote pair programming? Honest question here, is pair programming still a thing?

I don't know about strict pair programming where one person instructs and the other person types, and then they switch after a while.

But.. if you mean two or more devs on a call looking at code.. then that is very much a thing.

> Why would I be entitled to interrupt someone to review my code, just because they are sitting next to me?

Yes, and because your work depends on them.

When you have to mail a package do you barge ahead of the line of people too?

If I’m a mailman and this is urgent package - absolutely.

>Honest question here, is pair programming still a thing?

It's still by far the most effective tool for certain tasks. Inherit an extremely complex codebase with 50 levels of abstraction? You could spend a week tinkering with it, or you could step through the code with the guy who wrote it for 30 minutes. But it's not something you'd want to do every day, or even frequently.

> Remote pair programming? Honest question here, is pair programming still a thing?

I’ve just encountered it at my newest job.

A little of it actually seems good, but more as a “show and tell” of how some part of the system you know operates, that may include writing a little code in service of better learning.

Otherwise it seems to be a great way to get two developers to have the output of half a developer.

Pair programming isn't widely practiced for obvious reasons: It looks like you just made your code twice as expensive. There are studies justifying the cost by showing it can be recovered with less testing, code review, and bug hunting. But that evidently hasn't been persuasive. Also, anyone familiar with statistical quality control (SQC or SQA) would look at pair programming and see 100% inspection. Very suboptimal in manufacturing.

Still, pair programming makes sense in the abstract: Coding is not manufacturing. Applying SQC to code is nonsensical. Under the circumstances, 100% inspection is all you've got. Pair programming probably makes sense in cases where minimizing bugs at every step, right down to the creation of every line of code, is needed because the cost of a bug explodes the longer it exists. Probably rare cases. But worth knowing to know that coders are not working on a production line.

This makes sense if you see programmers as cogs in your code factory that produce exactly 1 coder day of code per day.

If, however, you see them as humans with different skills that can be shared amongst each other, then pair programming makes a lot more sense.

Yes indeed. I remember a full team of old mainframers going together in a room with printed code and review it together. 500% inspections. Many pieces of code would hold for decades without major refactoring. A lot of the code being produced today is quite garbage IMO, and you can see that in the infrastructure requirements it brings with it, growing faster than our bandwidth.

have you ever done pair programming? like actually sit there and be forced to do it? It's absolutely infuriating to anyone who values anything. I spent 20min trying to convince my "pair" that it was ok for a comment to be a sentence fragment and not a complete sentence. Every keystroke is the same conversation over and over. After that experience, i pulled rank and said i will never pair program again and haven't since.

Pairing does not work if you believe you have to convince the other person that you are right.

What you did wasn't "pair programming", it was an argument.

It can be terrible in practice. Same with test driven development, also annoying if instituted by proclamation. A lot of code doesn't need these formalisms. By that I mean: Do it very carefully in circumstances where there is clear justification, and with an adequate budget for tooling and support. These techniques were invented before there was good tooling to support them, which makes bad outcomes a lot more likely.

It sounds like you were just using your pair to type for you.

> It's absolutely infuriating to anyone who values anything

It's not really your place to say what's infuriating to others when your pair programming experience with a _single_ (somewhat neurotic) programmer was irritating. In my experience, pair programming has been a delightful two-way share of ideas that was both refreshing and productive (but I'm not going to claim universality or such an experience).

Pair programming probably does suck when one side is extremely impatient and overbearing.