undefined | Better HN

0 pointspydry11mo ago0 comments

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?

0 comments

phito11mo ago

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.

pydryOP11mo ago

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.

j / k navigate · click thread line to collapse