For the last two weeks, a little researcher in me has enjoyed the opportunity to eavesdrop on two programmers pairing. Don't get this post confused with stuff I talk about when I speak of my work, as for the past two weeks, I've been on vacation. That means I do whatever I feel like, without having to consider what my company expects or would benefit from.
This pair of programmers is an interesting mix. They shared an interest to a problem that needs an open source solution (a testing tool). They are pairing on a problem one knows deeply, and on language the other knows deeply. In fact, the first developer had his first experience on the language three weeks ago in a code retreat trying it out on pairing on game of life.
They pair remotely, sharing voice and screen and I can recognize that they are doing strong-style pair programming, without ever agreeing specifically on the style.
In strong-style pair programming, for an idea from your head to get to the keyboard must go through someone else's hands. A phrase often used around teaching this style is "no thinking at the keyboard" as driver, and this dynamic was particularly fascinating to monitor.
It's clear in this pair that the one who knows the problem deeply is the one navigating - hands off keyboard. This is probably also a result of the fact that he does not have a development environment in the language set up at all, so they will be working on the other's computer. He is navigating by concepts. Also, it's clear that over the two weeks, the navigator who did not know the language before has become very comfortable with the language, picking up ways of how to do the conceptual things as they go on with the implementation.
Listening to them, I feel more that the simplification of saying "no thinking at the keyboard" is harmful one. It's "no decisions of direction at the keyboard". There's plenty of thinking happening, and in this pair, it's very obvious that both programmers bring in a piece of the puzzle and neither could implement the solution all by themselves.
Eavesdropping on programmers also reminds me on the stuff I think while eavesdropping. It makes me generate ideas of what I would test if I would test that stuff. Some of it would be stuff that in a mob I would correct/contribute right away. Others I would intentionally part for later, as I feel they would just divert focus now.
This pair of programmers is an interesting mix. They shared an interest to a problem that needs an open source solution (a testing tool). They are pairing on a problem one knows deeply, and on language the other knows deeply. In fact, the first developer had his first experience on the language three weeks ago in a code retreat trying it out on pairing on game of life.
They pair remotely, sharing voice and screen and I can recognize that they are doing strong-style pair programming, without ever agreeing specifically on the style.
In strong-style pair programming, for an idea from your head to get to the keyboard must go through someone else's hands. A phrase often used around teaching this style is "no thinking at the keyboard" as driver, and this dynamic was particularly fascinating to monitor.
It's clear in this pair that the one who knows the problem deeply is the one navigating - hands off keyboard. This is probably also a result of the fact that he does not have a development environment in the language set up at all, so they will be working on the other's computer. He is navigating by concepts. Also, it's clear that over the two weeks, the navigator who did not know the language before has become very comfortable with the language, picking up ways of how to do the conceptual things as they go on with the implementation.
Listening to them, I feel more that the simplification of saying "no thinking at the keyboard" is harmful one. It's "no decisions of direction at the keyboard". There's plenty of thinking happening, and in this pair, it's very obvious that both programmers bring in a piece of the puzzle and neither could implement the solution all by themselves.
Eavesdropping on programmers also reminds me on the stuff I think while eavesdropping. It makes me generate ideas of what I would test if I would test that stuff. Some of it would be stuff that in a mob I would correct/contribute right away. Others I would intentionally part for later, as I feel they would just divert focus now.
