1. I just can't keep up with Vim wizards, they dart around a file at the speed of thought and I can't keep track of what they're doing.
2. It's too much social stimulation, which I find incredibly exhausting.
Whilst I don't enjoy people watching me as I work, it's not one of the root fears for me, because I don't see pair programming as being a watching vs doing equation.
To address your two points, it is bad form for a person driving to move too quickly. If you are not explaining your thoughts and are moving so fast that your navigator can’t follow along you are no longer pair programming and have lost all benefit.
Second, social stimulation can be an issue. But it is important to take lots of breaks, and to have time away from pairing to think and work on your own.
That would make me uncomfortable as the programmer, since I'd want to code at my own pace.
That said, I imagine I'd necessarily slow down if I needed to explain the code, to help pin down a bug or get feedback, for example. So I guess pair-programming would be useful sometimes. I wouldn't like it if I had to do it all the time, though.
> That would make me uncomfortable as the programmer, since I'd want to code at my own pace.
OK, but then that's not pair programming. It's you programming with someone watching.
With pair programming though, you're not coding at your own pace; you're solving a problem with a colleague and occasionally writing a bit of code. It should be mostly talk - and if there's a bit of grind work coming up, that's when you part ways.
> I wouldn't like it if I had to do it all the time, though.
Few people do, it costs a lot of energy to do social stuff - unless you're extroverted and energized by the social aspect of it.
Precisely, pair programming is mostly about reducing the feedback loop and leveraging different modes of thinking (low- vs. high-level, driver vs. navigator[1]). I think this is just one of the things that are a bit hard for people without pairing (or XP) experience to grok.
How this looks in practice: https://sonnet.io/posts/snakes/
[1] https://martinfowler.com/articles/on-pair-programming.html
My rule of thumb when there's this level of knowledge disparity is that the person who doesn't know what they're doing is the only one allowed to touch the keyboard. That way the knowledgeable person is forced to slow down and explain until the other person actually understands what they're intending.