2 ms·

I think the experience difference and approach differences are difficult yo overcome. If you are pairing with mostly other senior engineers, maybe it is less of

I think the experience difference and approach differences are difficult yo overcome. If you are pairing with mostly other senior engineers, maybe it is less of an issue. The other skill that varies greatly is the ability for abstract visualization. I build a model of what I'm working on almost immediately. It takes others time to slowly build it up and draw pictures, etc. I could tell them what I think it should be but they are supposed to be driving. Otherwise, I'm designing it and they are just implementing it and that doesn't feel very pair oriented.

mikekchar 9y ago
I won't lie. They are difficult to overcome. I really advocate going a full XP style if you are going to do pair programming. Getting really good at TDD makes such a huge difference. You can drill down into one aspect of the design and build it up -- because you are isolating it, it reduces the amount of conversation necessary. You can say, "How about we start with object X and see where it takes us", even if you have a pretty good idea where it's going to go. Those who are lost are given something to hang on to and focus on. But it's also important to be flexible because often you have a whole architecture in your mind and your pair starts taking it in another direction. It's good to allow it to move forward, checking in code as you go, without fear that it's all somehow going to be ruined. On my team, I often say that I know exactly one way to be really, really successful -- XP. There are other ways to be successful, I'm sure, but that's the way I know how to do it. If you start mixing and matching techniques, it gets harder and harder to find a path towards excellence -- because you are walking through the unknown. Although I'm a huge advocate for pair programming on an XP team, I don't really recommend it for other types of teams because I don't know how to make it work well. (Just to be clear, I can be successful using other techniques, but the kinds of success I've had on highly functional XP teams, I've never seen anywhere else before)

mikekchar 9y ago

I won't lie. They are difficult to overcome. I really advocate going a full XP style if you are going to do pair programming. Getting really good at TDD makes such a huge difference. You can drill down into one aspect of the design and build it up -- because you are isolating it, it reduces the amount of conversation necessary. You can say, "How about we start with object X and see where it takes us", even if you have a pretty good idea where it's going to go. Those who are lost are given something to hang on to and focus on. But it's also important to be flexible because often you have a whole architecture in your mind and your pair starts taking it in another direction. It's good to allow it to move forward, checking in code as you go, without fear that it's all somehow going to be ruined. On my team, I often say that I know exactly one way to be really, really successful -- XP. There are other ways to be successful, I'm sure, but that's the way I know how to do it. If you start mixing and matching techniques, it gets harder and harder to find a path towards excellence -- because you are walking through the unknown. Although I'm a huge advocate for pair programming on an XP team, I don't really recommend it for other types of teams because I don't know how to make it work well. (Just to be clear, I can be successful using other techniques, but the kinds of success I've had on highly functional XP teams, I've never seen anywhere else before)