I’d recommended a group consider pair-programming as a technique to help everyone learn more about the system. One of the developers came up to me later and said, “How do I give feedback while pairing?” I said “Nicely,” and promised more specifics. Here are my guidelines for pairing feedback:

• Explain the effect on me for that line of code/writing. “I’m confused by that…” with the specific confusion.
• Recognize when it’s time to change positions. If I’m the navigator and I object constantly, it’s time to change seats.
• If one person says, “I wouldn’t do it that way,” the other person has the right to say, “Ok, but we both have to live with the product; this isn’t just yours.”
• Don’t label the work product. “This code is awful” is useless feedback. It doesn’t explain what’s awful, and the label feels like it’s on the person, not the work product.
• Meta-feedback: Listen for laughter or some other expression of enjoyment. If no one is laughing or obviously enjoying the pairing, something could be wrong. When Esther and I stopped laughing when we were writing Behind Closed Doors, we knew it was time to stop for the day.

I’m sure there’s more and I’m blocked for now. If you have a favorite mechanism for feedback while pairing, please comment. And read some of Esther‘s writings on feedback, especially Peer-to-Peer Feedback.

I’m teaching project management (and some hiring) workshops in Israel. I’ve caught up with timezones, so I may even be able to post this week.

I attempted to explain why pair programming works to some skeptical project managers last week. I explained that in the best environments, a person can work 6 hours a day on technical work. And that person creates defects as well as creates work product. When pairing, the person can work for about 2 hours at a time, 2 or 3 times per day. But the created defect rate is much lower. The skeptics in my class pounced on the time spent working. I think I dealt with that question. But the real question that stumped them was how to do performance evaluations and give raises to pairs.

The problem I have is this: how do these managers give performance evaluations and give raises now? No one writes code or tests or whatever in a vacuum. All software is interdependent. So why is pairing somehow different? If we always performed peer review or inspections, wouldn’t it be the same problem?

I need more words or ideas to help explain pairing more successfully. Or, I need some more arguments to help people overcome their fear/resistance to this new-to-them idea. Got any words for me?

I’m working with Esther this week on the book. We’re editing (and continuing to pair-write and pair-edit). Today, one of the things we addressed were the comments dealing with the people we name in the book. We hadn’t done a good job drawing our readers in to care about the people. So we’re fixing that. One technique we’re using is to fill out a character sheet about each character.

I already had a picture in my head for each character. Esther may have, and her picture is different from mine. At one point today, I joked, “Can’t you just read my mind?” Esther replied (with a straight face), “No, your skull is too thick.”

Well, we lost about 5 minutes of work with that. I was almost rolling on the floor. Esther laughed almost as hard as I did.

Even when pairing, people can’t know what the other person is thinking. You can be headed in the same direction, but still veer off. And that’s ok. We don’t have to be clairvoyant to be effective working with each other. And I still think that pairs who laugh together are very effective.