Pairing up
Last week it seemed to me that something had been going awry in our pair challenges. I felt that our lack of pairing had left us somewhat unpracticed in team development. I thought maybe we had been concentrating on getting our hands-on coding. I mentioned it to Chuck and he assured me that this was probably okay, at least for the beginning of the course. But he challenged me to spend this week pairing with others and letting them lead.
So that’s what I did, with the exception of working on the mail code for our team project, I tried to work with others in the class. We worked on our Cards Against Humanity game, modeling it in the database and learning how to set it up in Rails, and I looked over the shoulder. Here are the challenges I faced:
- Backseat driving
- This is when you want to take over but can't, so you overspecify, and generally micromanage. The goal of pair programming is to be an auxillary, or supplemental brain, not the only one.
- “I'll work on this thing.”
- This is when you get distracted with some research project, or other task, and the pair basically splits in two. Sure, sometimes you have to divide and conquer, but sometimes, divided, you fall.
- “I don't understand”
- If you don't know what's going on, maybe you should be typing.
Although I expected these challenges, it was interesting to face them head-on and get a feel for them. There’s an itchy, restless feeling I get when I’m bored, or ready to move on. I have to practice patience then to be helpful to my partner. I’m not strongly tempted to backseat drive, but I worry about being condescending, when questioning my partner.
I look forward to next week’s challenges.