Way back in 1998, I worked at the shipping dock of a distribution warehouse, on the 2nd shift. I was the only guy there most days.
My job was to stack all the boxes for a particular store on the pallet bound for that store. When the stack was tall enough, I wrapped the pallet in plastic and wrote the store number on the plastic.
At that point, there was a QA check to ensure that the number on the plastic matched the number on the boxes. Since I was the only guy in shipping during that shift, guess what happened?
Yes, you're right. I had to do the QA check on my own work, immediately after doing it, somewhere between 4 pm and midnight. The company is very lucky I only ever screwed that up once during the entire summer. That taught me a valuable lesson for the entire rest of my life:
Always separate the QA from the work in a meaningful way.
In pair programming, as long as one person is actively working, and the other verifying, that works tolerably well, but if those roles start to blur, you're asking for trouble. And the longer the pair works, the more likely that is to happen. The two pairs of eyeballs become less like a front view plus side view and more like a stereoscopic image from nearly the same angle.
You're also setting up a mutually assured snitching situation, where both people in the pair want to declare that they are both burned for the day and need a slack break, but neither can be the one to call it. If you're inclined to try pairing on your team, I'd recommend no more than three consecutive hours in a pair, followed by at least one hour of less intensive individual work. While I have been able to stay in hyperfocus for much longer than that individually, there's no way I could with another person in the room--probably not without the assistance of a research psychologist, anyway.
Comments
Way back in 1998, I worked at the shipping dock of a distribution warehouse, on the 2nd shift. I was the only guy there most days.
My job was to stack all the boxes for a particular store on the pallet bound for that store. When the stack was tall enough, I wrapped the pallet in plastic and wrote the store number on the plastic.
At that point, there was a QA check to ensure that the number on the plastic matched the number on the boxes. Since I was the only guy in shipping during that shift, guess what happened?
Yes, you're right. I had to do the QA check on my own work, immediately after doing it, somewhere between 4 pm and midnight. The company is very lucky I only ever screwed that up once during the entire summer. That taught me a valuable lesson for the entire rest of my life:
Always separate the QA from the work in a meaningful way.
In pair programming, as long as one person is actively working, and the other verifying, that works tolerably well, but if those roles start to blur, you're asking for trouble. And the longer the pair works, the more likely that is to happen. The two pairs of eyeballs become less like a front view plus side view and more like a stereoscopic image from nearly the same angle.
You're also setting up a mutually assured snitching situation, where both people in the pair want to declare that they are both burned for the day and need a slack break, but neither can be the one to call it. If you're inclined to try pairing on your team, I'd recommend no more than three consecutive hours in a pair, followed by at least one hour of less intensive individual work. While I have been able to stay in hyperfocus for much longer than that individually, there's no way I could with another person in the room--probably not without the assistance of a research psychologist, anyway.