[BoardsOfCanada]

As someone who has programmed for a very long time but only done pair-programming a lot last few years, the big things in my opinion is:

- If you're the driver (handles the typing), don't allow yourself to be stressed and just type things someone else tells you to type.

- Language is really bad at comunicating where to make a change on a gigantic screen of text, expect yourself and others to become a bit frustrated at times, but it's at the difficulty of communicating things, not that the other person is dumb. "And change the type to bool. No not that one. Go to the end of the line, then back to the last bracket. No, the line you were at. Yes. Now go to the last bracket. Change to bool." And then take a second to understand why, asking if necessary, becuase it might get more difficult to understand later.

- It's extremely difficult not to get lost when someone else is navigating between tabs, especially if you don't know the code well (and sometimes even if you do).

[tialaramex]

I would guess that Keep Talking And Nobody Explodes would be a good exercise to learn what the problem is without getting into domain specific skills.

https://keeptalkinggame.com/ (ideally play this with the defusal in VR)

KTANE even has (to a greater extent, and for humour) the ambiguities that can trouble talking to somebody about programming, like offering "YES", "AND", "&" and "NO" as options somebody needs to pick quickly.

[pooya72]

That's helpful, thanks!