Hi Jim et al.,

Regards pair programming, nothing new about those clothes :-), although it does seem to be enjoying a sort of 'retro' return to fashion.

I'm old enough to know there is no right way of doing things, and I object when I see things done 'at any cost', or 'just because'.

Pair programming involves double the cost, and needs to deliver at least twice the value, to be justifiable.

Fortunately, I'd argue there is value...
- Less is more. When pairing, refactoring is done at the point of development, rather than as a later pass. Code is expensive to develop and maintain, and less is more. Fewer lines of code, fewer iterations...

- Creativity. Producing innovative code is not a conveyor belt activity. Programmers can get stuck, take dead-ends. Individuals can get stuck on personal 'pet' ideas, which take a project on a tangent. These can get ironed out when collaborating. Code can be more creative, and broadly appealing and attractive, when people have collaborated and shared different viewpoints during its creation. This can and should be fun!

- Consistency, and social responsibility. We are strongly individualistic, anti-dogmatic, society, and there is argument that developers should choose whether to pair or not. This pick-and-mix design/development philosophy causes problems of its own. For instance, I agree strongly with this comment...
>>I find a strong correlation between it being understandable and it being pair programmed. I am no longer looking at the historical content of a single person's mind.
Shouldn't this be social responsibility of developers towards their colleagues, since codebase is a social product?

Concerning pair programming and TDD. I personally think TDD (and design by contract) philosophy, can contribute to overly constrained code. I could argue that Pair programming helps mitigate this, because the pairing partner might point out more general applications for interfaces, and avoid a tendency to beat the potential for reuse out of the code...

Concerning code reviews, I have found they are unpopular among some developers, and can get 'forgotten' fairly quickly, as a thing you can get away with not doing. Pair programming can give similar benefits as code review, at the point of coding, rather than retroactively.

In summary, I respond:
- pair programming as dogma is not an ideal approach.
- pair programming as pick-and-mix is also not ideal
- pair programming without accountability of value is likely to be less not more productive
- we don't go to work just for fun. If you don't like pair programming, be creative and invent alternatives. We will thank you for inspiring us with new approaches...

:-)
Matt
 

From: Jim Collins [mailto:[address removed]]
Sent: Tuesday, January 29,[masked]:40 AM Eastern Standard Time
To: [address removed] <[address removed]>
Subject: [ljc] Am I a bad programmer if I do not like pair programming?
 

Hi,

I was wondering if there are other programmers out there who feel they are bad programmers because they do not like pair programming.

I feel that I am much more productive working on my own and it is how I enjoy to work. If I am working on something particularly difficult then I will often ask a colleague what they think and when I commit code I also talk my colleagues through what I have done in a code review. That is how I have always worked and how I enjoy working.

I sometimes get the feeling that pair programming is like the emperors new clothes. No one will stand up and say I don't like this so we all continue in this vicious circle :).

Thanks

Jim




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Jim Collins ([address removed]) from LJC - London Java Community.
To learn more about Jim Collins, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful.



--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Matt Pearce ([address removed]) from LJC - London Java Community.
To learn more about Matt Pearce, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]