Comments on: Pairing http://www.simonlin.ca/2006/07/31/pairing/ A site by Simon Lin Tue, 24 Jun 2008 17:59:51 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Simon Lin http://www.simonlin.ca/2006/07/31/pairing/comment-page-1/#comment-6 Simon Lin Wed, 02 Aug 2006 20:14:08 +0000 #comment-6 <p>I totally agree with you this time. It should be an exercise, a spike. Those code should not be checked in.</p> I totally agree with you this time. It should be an exercise, a spike. Those code should not be checked in.

]]> By: Vlad http://www.simonlin.ca/2006/07/31/pairing/comment-page-1/#comment-5 Vlad Tue, 01 Aug 2006 23:23:07 +0000 #comment-5 <p>I don't think it's as bad as code review. Formal code reviews involve more than two people. They involve a meeting with various people playing various roles and all sorts of rather crazy stuff. Also, a bug fix should generally represent a reasonably small amount of code, usually no more than 1 day of work. If it's more than that, I agree that pairing may be a better way to go. Pairing is good but like I said, people do need time alone with the code. At a minimum, I propose allowing newbie pas developers to fix the bug by themselves without checking in, then to fix the bug again with a pair. The key is let someone examine the code at his/her leisure, to explore and retrace through the code, to try stuff out - effectively I start to realize to treat the bug fix initially as a spike.</p> I don’t think it’s as bad as code review. Formal code reviews involve more than two people. They involve a meeting with various people playing various roles and all sorts of rather crazy stuff. Also, a bug fix should generally represent a reasonably small amount of code, usually no more than 1 day of work. If it’s more than that, I agree that pairing may be a better way to go. Pairing is good but like I said, people do need time alone with the code. At a minimum, I propose allowing newbie pas developers to fix the bug by themselves without checking in, then to fix the bug again with a pair. The key is let someone examine the code at his/her leisure, to explore and retrace through the code, to try stuff out – effectively I start to realize to treat the bug fix initially as a spike.

]]> By: Simon Lin http://www.simonlin.ca/2006/07/31/pairing/comment-page-1/#comment-4 Simon Lin Tue, 01 Aug 2006 15:04:08 +0000 #comment-4 <p>"That gives the more experienced pair an opportunity to make adjustments or even veto the changes altogether, say in the case where the changes are in the wrong place."</p> <p>That's pretty much code review, which has its own problem. I always feel wierd telling people what they did wrong after they've done it.</p> “That gives the more experienced pair an opportunity to make adjustments or even veto the changes altogether, say in the case where the changes are in the wrong place.”

That’s pretty much code review, which has its own problem. I always feel wierd telling people what they did wrong after they’ve done it.

]]> By: Vlad http://www.simonlin.ca/2006/07/31/pairing/comment-page-1/#comment-3 Vlad Tue, 01 Aug 2006 10:14:28 +0000 #comment-3 <p>"During the meeting, one of our junior developers said that he/she would like to have some alone time fixing bugs so he/she can learn more about the system without interference."</p> <p>I think it's important for new developers on the team to have some alone time with the code. When I started on the project, I had a hard time initially understanding how everything fit together, and it's hard to "grok" what is going on with someone else sitting next to you who is always moving at a much faster pace. So perhaps letting a new developer work on bugs alone is not such a bad idea after all. I would propose having the new developer go over the bug fix with a pair before checking in though. That gives the more experienced pair an opportunity to make adjustments or even veto the changes altogether, say in the case where the changes are in the wrong place.</p> “During the meeting, one of our junior developers said that he/she would like to have some alone time fixing bugs so he/she can learn more about the system without interference.”

I think it’s important for new developers on the team to have some alone time with the code. When I started on the project, I had a hard time initially understanding how everything fit together, and it’s hard to “grok” what is going on with someone else sitting next to you who is always moving at a much faster pace. So perhaps letting a new developer work on bugs alone is not such a bad idea after all. I would propose having the new developer go over the bug fix with a pair before checking in though. That gives the more experienced pair an opportunity to make adjustments or even veto the changes altogether, say in the case where the changes are in the wrong place.

]]>