Why would I be entitled to interrupt someone to review my code, just because they are sitting next to me?
Always on zoom? No, thanks. It invariably devolves into micromanaging.
Constant KPI awareness? Most companies cannot even agree on how a valuable KPI looks like.
Remote pair programming? 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.
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.
Yes, and because your work depends on them.
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.
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.
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.
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.
What you did wasn't "pair programming", it was an argument.
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.