• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • fred rosenberger
  • salvin francis

Pair Programming thoughts

 
Ranch Hand
Posts: 677
1
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have started Pair Programming where i work, I have been teamed up with another chap, and I find the experience unnerving. I dont mind discussing collaborating on the design, but i find it very unerving to sit there coding with someone next to me watching.

I find it breaks my concentration.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess I can relate to that. I think pair programming can be very valuable if you're tackling a complex problem and you really need another pair of eyes or a second left hemisphere. I couldn't work that closely with someone - anyone - full-time though, I'd go nuts.
 
Tony Evans
Ranch Hand
Posts: 677
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think most people when coding work better on there own, mistakes can be checked through a good peer review.
 
Sheriff
Posts: 4981
319
IntelliJ IDE Python Java Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think pair programming is an extremely valuable and effective technique, but I also think it has it's place and that place is not all the time. Half of the 'trick' is knowing when to pair and when not to pair. I find great value in working in a pair in that the session becomes a continuous conversation and the output of those conversations is high quality, functional code. If we don't quite understand the problem we're trying to solve then sometimes a pair programming session results in no code at all, but we still achieve greater knowledge of the problem which is extremely valuable too.

There are times though when pair programming is not all that effective. From time to time I'll have a half baked idea in my head that is just not ready to come out as any comprehendible sentence, and in this case I might just want to close off from the outside world for a morning and incubate it. After which I'll share it with the team, if it's worth sharing.

Tony Evans wrote:
mistakes can be checked through a good peer review


This is an interesting point. In my experience, the quality of that peer review is directly dependent on the amount of time left before the peer review is performed. The longer it's left before reviewing, the lower the quality of that review will be. For example, say a colleague writes some code, checks it in, and submits a review ticket for me to review it. I'm a bit busy and it takes me a few days to get round to doing the review. The code is functional and has a bit of test coverage but the layout is untidy, there's been some poor variable and method naming choices, and I have a nagging feeling that the test coverage is missing something. At this point I'm going to feel like a bit of a arse if my entire feedback is "Don't like the name of this", "This method is untidy", "This method is too long", "What's this variable for?", etc. etc. It all feels a bit petty and I've yet to find an effective way to provide this feedback without it feeling like the person is being picked on.

With pair programming, the peer review is immediate and just forms part of the ongoing conversation. To question the naming of a variable at this stage is just part of the design process. You'll often hear me saying things like "Whoa whoa whoa there, you're not getting away with that! Name it something sensible please", "Hey this method is getting a bit out of hand, I think we should split it up", "This just doesn't feel right, I think we're losing the plot a bit".

These small course corrections during development are easily dealt with. Which is in contrast to the "3-days later" peer review where your feedback is "No sorry, this does not solve the problem. Complete rework required".
 
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It can have some value, but to do it all the time.. That idea comes from the management again, who thinks the developers are all nerds that dont communicate, and if they are forced to communicate all problems would be solved. It is not that simple. Sometimes you need to talk about a problem, sometimes you need some time and space to think about it by yourself.
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jan de Boer wrote:It can have some value, but to do it all the time.. That idea comes from the management again, who thinks the developers are all nerds that dont communicate, and if they are forced to communicate all problems would be solved. It is not that simple. Sometimes you need to talk about a problem, sometimes you need some time and space to think about it by yourself.



I'm not sure it just comes from management. In fact, I've never heard someone who didn't have a development background advocate pair programming at all. Someone who doesn't seems more likely to have the view "but then you're only getting half as much work done".

(I've never actually had the chance to pair program - we don't do it here - but I'd like to try it).
 
Bartender
Posts: 1204
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Cooke wrote:I think pair programming is an extremely valuable and effective technique, but I also think it has it's place and that place is not all the time. Half of the 'trick' is knowing when to pair and when not to pair.



I couldn't agree more. It has its place, which isn't all day every day.


With pair programming, the peer review is immediate and just forms part of the ongoing conversation. To question the naming of a variable at this stage is just part of the design process. You'll often hear me saying things like "Whoa whoa whoa there, you're not getting away with that! Name it something sensible please", "Hey this method is getting a bit out of hand, I think we should split it up", "This just doesn't feel right, I think we're losing the plot a bit".

These small course corrections during development are easily dealt with. Which is in contrast to the "3-days later" peer review where your feedback is "No sorry, this does not solve the problem. Complete rework required".



Exactly. One of the roles of the other person in the pair is to act as the angel on your shoulder convincing you to take time to do things that you already know you should do.

One thing to keep in mind is that pair programming takes two people. If each person on their own can produce* X, then pair programming doesn't make sense unless the pair can produce 2X or more.

* Granted, measuring programmer productivity is quite a challenge indeed, including even agreeing on what you want to measure. How do you objectively quantify functionality, quality, maintainability, performance, security, etc.?
 
Tim Cooke
Sheriff
Posts: 4981
319
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For me it's not a "management" mandated thing. It's more of a "Hey, can you spend an hour or two working with me on this thing please?".

The choice to pair or go it alone is decided by the developers. So Matthew, you say "we don't do it here", and I say you shouldn't wait to be asked. It's easy to try, just get a willing colleague and ask them to work with you on a problem at your computer for a while.

By the time you're being asked to do it by management it's too late. You'll have the added feelings of resentment of being micromanaged to contend with on top of the unfamiliarity of working that closely with someone on a development task.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Cooke wrote:The choice to pair or go it alone is decided by the developers. So Matthew, you say "we don't do it here", and I say you shouldn't wait to be asked. It's easy to try, just get a willing colleague and ask them to work with you on a problem at your computer for a while.



"We don't do it here" is really "we seldom have more than one developer assigned to a project". In some cases I can do that, and I would when I run into problems, but otherwise nobody else is anywhere near familiar enough with the application (and in the case of one system I maintain, the language) to really make it effective.

I agree that if anything is going to change it's going to be developer driven. I (mostly) use TDD simply because I decided I was going to do that. Nobody has objected.
 
Ryan McGuire
Bartender
Posts: 1204
22
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Surprised nobody has pointed to this yet...

 
Tim Cooke
Sheriff
Posts: 4981
319
IntelliJ IDE Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Very good Ryan, if a little creepy.
 
Jan de Boer
Ranch Hand
Posts: 974
11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Matthew Brown wrote:I'm not sure it just comes from management.



I actually meant the idea to do it all the time, and that it is the panacea to all problems. Well, in my case, that came from a manager then.
 
author & internet detective
Posts: 40676
827
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jan de Boer wrote:

Matthew Brown wrote:I'm not sure it just comes from management.



I actually meant the idea to do it all the time, and that it is the panacea to all problems. Well, in my case, that came from a manager then.


<sarcasm>You mean pair programming isn't a silver bullet? Shock! </sarcasm>
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic