HandsAtTheReady

> someone right next to you hovering while you are trying to develop

The pair is a collaboration. They develop together.

> Do you really need someone over your shoulder to make sure you can turn requirements into code?

I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.

I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.

> The cases you see at Bloomberg are well evidence, lack of tech is not a problem here.

From TFA "From about 2007 until 2012, Banamex USA, a Citi subsidiary, processed more than $8.8 billion in transactions with almost no oversight.".

> The cases you see at Bloomberg are well evidence > the crimes were recorded Blockchain or not

imglorp suggested "Anyone can audit the complete trail of funds from source to holding to destination.". Was this evidence you mention publically auditable (i.e. what imglorp's suggesting would help)?

> Blockchain isn't going to help with that

It's at least plausible that a publically auditable log would have helped spot these issues.

I've been at places that do those too. But they weren't the environment that has enabled my best work.

In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.

+1 to XP.

Pairing removes many barriers to development:

* built-in code review

* knowledge sharing: removes silos

* helps avoids overengineering (few pairs have the same overengineering idea, so you tend to settle on a decent un-overengineered solution)

TDD, which I'm not fully convinced on, acts a clock for pairs: one person writes a test, one person writes the implementation, flip roles, repeat.

Other XP practices: everyone works at HEAD, deploys from HEAD, retrospectives.

Small features went from discussing with customer, to writing the implementation, tests, monitoring, and deploying it in half a day.

The disadvantages of ~full pairing: remote is harder to support, I missed getting into flow, fixed working hours.