Pair Programming; Pair Administration.
I like pair programming1.
However, long gone are the days where pairing benefits me personally to a great degree, educationally. These days my pair programming mainly keeps me on-task and away from the dread onset of Nerd ADD, which is itself a Good Thing.
Being the clear Junior in a pair is generally my preferred position; I get to pair with someone who knows a field better than I do and devour their precious knowledge while (hopefully) providing a service to them by keeping them on task and helping to further cement and/or renew their understanding of the subject by taking a teaching role.
However, when it comes to being a unix administrator, or even a unix shell user, whenever I pair with a peer2 or better I learn new things. And I’ve been a unix user for over ten years and a (admittedly casual) server administrator for over 5 now.
Most commonly, these new pieces of unix and/or shell knowledge come from being the shotgun in a pair programming situation: The driver does some small bit of shell magic, I pull the breaks and ask them to explain what these new, wonderful shenanigans are. Sometimes they’re little things like using !a in bash to repeat the most recent command starting with ‘a’. Sometimes they’re the inner workings of a unix system like editing a fstab.
Some things are necessary to manipulating a unix system. Turns out a lot of what you may personally take for granted isn’t actually in that category.
I’ve seen the same song and dance by observing others as well. Someone does some ‘voodoo’, and the other asks what they did. Knowledge is shared. It seems that unix administration is a lot like living in Manhattan; Local residents will often speak in a secret code exchanging Cartesian coordinates with each other proving that yes, they live here and, hey, maybe you’d appreciate the bagels at this intersection!
The important thing to realize here, though, is the strides I see personally in pairing with administration are completely local3. When I was a younger programmer, these information-exchange dances happened multiple times daily. I’ve just become too jaded to see them in my day-to-day operations, because they’re (usually) part of the standard mode of operations. Anything wildly different from my current problems and/or skill sets in software engineer that I hear generally gets discarded as irrelevant to my needs now. However, when I hear something similarly esoteric in a subject I am less close to, I’m all ears: This tidbit sounds interesting, and I should devote my brain to it.
Context is important. The obvious can seem awesome from a certain point of view, and the awesome can seem obvious!
Always Two There Are…
When you pair, there’s generally a tutor/tutee dynamic going on. The more unknown there is, the more “magical” it feels, and the more you appreciate sopping up all that new delicious knowledge. The closer you get to putting your magical 10,000th hour into something, the fewer ‘new’ things you see (or recognize as pertinent).
The important thing, it turns out, is not to dwell on the magical learning revelation sensation. Being the bottom of a pair may feel more “learny”, but being the top is no less good for you. As opposed to “learny” you get “cementy”, “practicey”, and “teachey”.
And sometimes you get to learn a thing or two, too.
That pairing can work for things other than programming shouldn’t surprise anyone, and the fact that pair programming is effective should not be controversial. Pairing is, essentially, a single teacher to single student situation. A master and an apprentice, who can switch roles at a moment’s notice.
If you like to pair with superiors, you need to parry peer pairing; but you won’t fair well and soon you may say farewell to your fare wellspring of employment. Do not fear peer paring; But do fear pear peeling. The pear peel is fair to the feel and swell for a meal.
…I’ll stop now.