Re: [ljc] Am I a bad programmer if I do not like pair programming?

From: Matt P.
Sent on: Tuesday, January 29, 2013 1:36 PM
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...


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?

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 :).



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.

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference, in collaboration with the LJC 12/13 Jun 14

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy