Comments on: Pair Programming/Helping/Working Collaboratively http://www.markhneedham.com/blog/2009/11/22/pair-programminghelpingworking-collaboratively/ Thoughts on Software Development Sat, 11 Feb 2012 23:17:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Awkward Coder http://www.markhneedham.com/blog/2009/11/22/pair-programminghelpingworking-collaboratively/comment-page-1/#comment-27121 Awkward Coder Mon, 23 Nov 2009 16:11:51 +0000 http://www.markhneedham.com/blog/?p=1860#comment-27121 IMO once you accept you don't know everything and you don't take the lead when pairing (sometimes), it becomes fun and very productive. The abilities to solve particular problems are rarely equally matched in pairs IMO. It's enjoyable being able to sit back and be a sounding board for ideas... IMO once you accept you don’t know everything and you don’t take the lead when pairing (sometimes), it becomes fun and very productive.

The abilities to solve particular problems are rarely equally matched in pairs IMO. It’s enjoyable being able to sit back and be a sounding board for ideas…

]]> By: Andy Marks http://www.markhneedham.com/blog/2009/11/22/pair-programminghelpingworking-collaboratively/comment-page-1/#comment-27088 Andy Marks Sun, 22 Nov 2009 21:53:43 +0000 http://www.markhneedham.com/blog/?p=1860#comment-27088 If alpha progs are above pairing, then I assume they're similarly opposed to reviews of their code... and what about testing of their code? Surely that's a no-no as it presumes there will be defects :-) If alpha progs are above pairing, then I assume they’re similarly opposed to reviews of their code… and what about testing of their code? Surely that’s a no-no as it presumes there will be defects :-)

]]> By: msuarz http://www.markhneedham.com/blog/2009/11/22/pair-programminghelpingworking-collaboratively/comment-page-1/#comment-27079 msuarz Sun, 22 Nov 2009 14:42:44 +0000 http://www.markhneedham.com/blog/?p=1860#comment-27079 I don't like the helping alternative. It kills the balance of a pairing session. The alpha whatever a**holes would always be doing the helping because they r too good to need help. The rest of us would struggle harder with problems before asking for help. Because pride is a very human thing. All in all the alpha-morons (i really disdain this alpha concept) would still build code that is clever in the best case. Most often what they do is write this super optimal scalable mambo jumbo that eventually becomes a framework an slave the betta programmer that simply don't get its awesomeness. So its natural to have different levels of knowledge distributed in the team. But if the alpha technical ppl are delta capable of working with others there's a problem. And solving it via the "helping" paradigm just keeps feeding the egos of this alpha nerds. Pairing is not about getting help, its about thinking through problems together (and having fun while at it). cheers mike I don’t like the helping alternative. It kills the balance of a pairing session. The alpha whatever a**holes would always be doing the helping because they r too good to need help. The rest of us would struggle harder with problems before asking for help. Because pride is a very human thing.

All in all the alpha-morons (i really disdain this alpha concept) would still build code that is clever in the best case. Most often what they do is write this super optimal scalable mambo jumbo that eventually becomes a framework an slave the betta programmer that simply don’t get its awesomeness.

So its natural to have different levels of knowledge distributed in the team. But if the alpha technical ppl are delta capable of working with others there’s a problem. And solving it via the “helping” paradigm just keeps feeding the egos of this alpha nerds.

Pairing is not about getting help, its about thinking through problems together (and having fun while at it).

cheers
mike

]]> By: Dave Rooney http://www.markhneedham.com/blog/2009/11/22/pair-programminghelpingworking-collaboratively/comment-page-1/#comment-27077 Dave Rooney Sun, 22 Nov 2009 13:32:33 +0000 http://www.markhneedham.com/blog/?p=1860#comment-27077 I understand the reluctance of people to pair right from the start, but I wonder how much time could have been saved by pairing immediately rather than waiting to ask for help once you were stuck or had a design decision to be made. My experience has always (and I mean always) been that pairing significantly reduces the latency between when I need help and when I'm conscious of needing help. Pairing forces me to think out loud, which can quite often make the answer to a decision obvious. Dave Rooney The Agile Consortium I understand the reluctance of people to pair right from the start, but I wonder how much time could have been saved by pairing immediately rather than waiting to ask for help once you were stuck or had a design decision to be made.

My experience has always (and I mean always) been that pairing significantly reduces the latency between when I need help and when I’m conscious of needing help. Pairing forces me to think out loud, which can quite often make the answer to a decision obvious.

Dave Rooney
The Agile Consortium

]]> By: Rixt Wiersma http://www.markhneedham.com/blog/2009/11/22/pair-programminghelpingworking-collaboratively/comment-page-1/#comment-27075 Rixt Wiersma Sun, 22 Nov 2009 12:34:24 +0000 http://www.markhneedham.com/blog/?p=1860#comment-27075 Remember the metaprograms that are recognized in NLP, for example Towards to -Away from? Your blog reminds me of the internal reference - external reference metaprogram. I guess coders with a strong internal reference wouldn't mind working alone and even when confronted with a design decision would be okay with coming up with a choice themselves, whereas an externally referenced person, would want to getas much input as possible before making the decision. Remember the metaprograms that are recognized in NLP, for example Towards to -Away from? Your blog reminds me of the internal reference – external reference metaprogram. I guess coders with a strong internal reference wouldn’t mind working alone and even when confronted with a design decision would be okay with coming up with a choice themselves, whereas an externally referenced person, would want to getas much input as possible before making the decision.

]]>