Pairing and code review are two central learning processes at Hacker School. They stir up different reactions in the mind.
Code review involves putting forward a piece of work, in some state of completion, and getting feedback on it if not large-scale suggestions for refactoring, or even outright refactoring itself. Naturally I want to look my best when showing my work to others for criticism. Even if it would be better to be "egoless", as the faculty advise, taking extra care is only to be expected and there's no point moralizing about it.
But pairing, in contrast — two minds driving just one pair of hands at the keyboard — has got to be casual to be effective. Ideally, both parties should be using the process as a chance to collaborate and learn without pressure. Even if one party is very much more advanced than the other, there is learning going on for both.
Unfortunately, most of the pairing sessions I've had have not been very casual. Today, a fellow student paired with me, meaning that he gave me a tour of his project and then made a few simple changes to it while I watched — it was all very easy-going and pleasant, but I sensed that he was a little uncomfortable throwing himself into a more substantial task in front of me, in which he might be stumped. I understand the hesitation, of course; I feel the same way, but I recognize that this is treating casual pairing as though it were a more "serious" code-review event.
The same happened with the two "pairing" sessions I had with one of the faculty last week and on Monday — she treated them as high level design sessions with pen and paper, rather than just plain pairing with one of us at the keyboard. Now, the sessions were an enormously helpful experience for me, all around. They were not stressful at all, and they enabled me to make a big step forward in the redesign of my project. But even so, they were not really the egoless and casual experience that pairing is supposed to be.
It seems that to do plain, casual pairing is going to cost me a bit more effort to bring into being, paradoxically.
Actually, I had one totally unplanned pairing experience at the end of the day today. I approached a faculty member with a problem I couldn't solve (how to unpack a list of lists in Python using a nested comprehension rather than loops) and she was stumped by it for a while, too. We tried a few different tactics but failed to solve it, in part because of mistaken assumptions on my part or hers. Eventually she found an "incantation" — a working solution that I think neither of us fully understood at the moment — on StackOverflow. Afterwards, we gradually made sense of why that solution worked, and came to considered the problem fully solved.
(Here is a schematic of the solution:
In: b_list = [[1, 2], [3, 4], [5, 6], [7, 8]]
[subitem for item in b_list for subitem in item]
Out: [1, 2, 3, 4, 5, 6, 7, 8]
This assumes the list of lists is only two levels deep.)
And that, I think, is a good example of how a successful pairing encounter might turn out — joint pursuit of working code as well as a grasp of why it works, without anyone being in charge, exactly, and both parties learning from the experience. I've had a good week all around, so far, but this was the high point. I want more of this.
I don't know if I'm capable of egolessness, but this was certainly a process unlike most of what I do at Hacker School — most of what I do is driven by my own expression of self. This, on the other hand, was driven merely by the desire to move forward an inch in writing a function, and it ended up setting me forward a good yard — and perhaps it taught the facilitator something, too. There was no pressure at all, and it was a delight. I must find ways to make this happen much more often.
[end]