4 ms·

> but rest assured that there are those who aren't built that way Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockhol

> but rest assured that there are those who aren't built that way 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.

bluk 6y ago
I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely. 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).
- sleepybrett 6y ago
  They've recently added shared buffers to the jetbrains stack as well (or at least goland): https://www.jetbrains.com/code-with-me/ https://www.jetbrains.com/code-with-me/ I have yet to try it out though.
  - Noumenon72 6y ago
    I tried it and it was pretty cool. You can each look through the code on the source machine independently, and summon each other to the place you're looking at. The changes I made were put into a separate changeset where the host could roll them back.
t0mbstone 6y ago
The best pair programming experiences I've had involve each programmer using their own laptops, each with a separate screen attached. 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.
jdlshore 6y ago
If you couldn’t figure out how to check your email or read documentation, it sounds like you were looking for reasons to fail. Pairing doesn’t mean you’re literally joined at the hip. You’re allowed to exercise judgment.
- commandlinefan 6y ago
  Well, no, in our case it literally did mean we were "joined at the hip" - we shared one computer.
  - CRConrad 5y ago
    "Bloing!" -- "Oh look, an email. Never mind, I'll read that later." "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.
suhlig 5y ago
> how do you check your e-mail? 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

bluk 6y ago

I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely. 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).

sleepybrett 6y ago
They've recently added shared buffers to the jetbrains stack as well (or at least goland): https://www.jetbrains.com/code-with-me/ https://www.jetbrains.com/code-with-me/ I have yet to try it out though.
- Noumenon72 6y ago
  I tried it and it was pretty cool. You can each look through the code on the source machine independently, and summon each other to the place you're looking at. The changes I made were put into a separate changeset where the host could roll them back.

t0mbstone 6y ago

The best pair programming experiences I've had involve each programmer using their own laptops, each with a separate screen attached. 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.

jdlshore 6y ago

If you couldn’t figure out how to check your email or read documentation, it sounds like you were looking for reasons to fail. Pairing doesn’t mean you’re literally joined at the hip. You’re allowed to exercise judgment.

commandlinefan 6y ago
Well, no, in our case it literally did mean we were "joined at the hip" - we shared one computer.
- CRConrad 5y ago
  "Bloing!" -- "Oh look, an email. Never mind, I'll read that later." "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.

suhlig 5y ago

> how do you check your e-mail? 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