4 ms·

None of those "fears" reflect why I tend to be resistant to pair programming: 1. I just can't keep up with Vim wizards, they dart around a file at the speed of

None of those "fears" reflect why I tend to be resistant to pair programming: 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.

Izkata 5y ago
> 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. 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.
- LR3sRdQ 5y ago
  This is a good rule.
ryanar 5y ago
Did you mean to say pair programming instead of code review? 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.
- andrewingram 5y ago
  oops yes, editing!
- barbs 5y ago
  > 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. 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.
  - Cthulhu_ 5y ago
    > That would make me uncomfortable as the programmer, since I'd want to code at my own pace. 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.
  - tome 5y ago
    > > 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. > 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.
rpastuszak 5y ago
>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. 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/ https://sonnet.io/posts/snakes/ [1] https://martinfowler.com/articles/on-pair-programming.html https://martinfowler.com/articles/on-pair-programming.html

Izkata 5y ago

> 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. 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.

LR3sRdQ 5y ago
This is a good rule.

ryanar 5y ago

Did you mean to say pair programming instead of code review? 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.

andrewingram 5y ago
oops yes, editing!
barbs 5y ago
> 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. 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.
- Cthulhu_ 5y ago
  > That would make me uncomfortable as the programmer, since I'd want to code at my own pace. 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.
- tome 5y ago
  > > 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. > 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.

rpastuszak 5y ago

>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. 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/ https://sonnet.io/posts/snakes/ [1] https://martinfowler.com/articles/on-pair-programming.html https://martinfowler.com/articles/on-pair-programming.html