[phito]

I’ve never really understood the hype around pair programming. In practice, it’s usually just sitting with a coworker who wants to chat and crack jokes while working. That’s fine socially, but I don’t see any productivity gains.

What I find actually useful is a short, focused meeting with the relevant people before coding. That way, we align on what’s being built, resolve confusion, and then I can just go write the code.

Once I'm typing, I don’t see how having someone else there helps. It mostly just gets in the way — we keep having to stop and explain what we're thinking, which slows things down. And usually the other person gets confused at some point, so I have to stop and explain things again to get them back on track.

[pydry]

The productivity gains come from:

* You get unstuck faster.

* When the passenger does background research/slacking stakeholders meaning that the driver doesnt have to context switch. Sometimes they even just know the answer to something you would have to spend 30 minutes researching.

* When the passenger spots something you didnt (antipattern, bug, problem) and they spot it quickly before you dug yourself a hole with it.

* When it makes it easier to take bigger decisions and bigger risks as a pair - risks/decisions most people wouldnt feel confident about taking solo.

* When those decisions are better - fewer rabbit holes are jumped into, more landmines are averted.

* When your respective coding philosophies developed over decades hit one another and you try to synthesize something that accomodates the best of both (this is next level pairing).

Mostly I find the productivity gains come from the quality of decisions being higher, which is invisible short term but overwhelming long term.

It doesnt help much if the person is very junior and needs to have everything explained but if theyre junior pairing is the best way to train and mold them into something better, which is probably what you want, right?

[phito]

I already get those benefits from focused pre-coding discussions and pull request reviews. They allow for high-quality decisions, involve more perspectives, and are asynchronous.

Pair programming might help when training juniors, since they need that level of hand-holding. But for experienced devs, constant back-and-forth while typing mostly just adds friction.

[pydry]

No. You dont. The feedback cadence is then wildly stretched out.

Instead of getting notification that you made a mistake within a few seconds of making it you are told at, say, 4pm, 45 minutes after you raised the PR, 4 hours after you made the mistake and in time for you to maybe fix it tomorrow. Also, if it was a rabbit hole mistake thats a whole lot of wasted work.

With PRs I find reviewers tend to miss more stuff (especially forest-not-trees stuff) because there are usually a lot of changes all going on at the same time and because the mental tax of trying to grasp all of the necessary context is higher.

The pre-coding discussions also do NOT provide the same value because many problems only become apparent after you've started coding. Only correctly anticipated problems are caught at that stage.

Code reviews and pre coding discussions are still good practices and add value of their own (especially because for some issues you do benefit from > 2 sets of eyes), but not as substitutes for pairing.

Pairing is also effective at training juniors and onboarding, but not only.