The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing.
Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed.
This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.
If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).
I have yet to try it out though.
You don’t. That’s what breaks are for (assuming personal e-mail).
> What if there's documentation that needs to be read?
- Define an objective together (e.g. „We‘d like to understand how the HTML progress element works“)
- Optionally, agree an a timeout
- Split (both reading at their own pace, on their own device)
- Join and discuss results
"Bloing!" -- "Oh look, I think I need to read that email now." -- "OK, I'll toodle over to my own desk and see if I've got any. See you in five."
A computer isn't a hip.
Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.