Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer, reviews each line of code as it is typed in.

But I just wonder the strategy still work in the case. For example

  • if they have a very different programming skill level.
  • if one never experience in the problem domain while another have.
  • Is it still OK if they have low programming skill level?

Could you suggest the pair programming strategy in the case above?

share|improve this question
13  
Make sure the two agree on who has the higher skill level and is supposed to coach the other. If these roles / skill levels are not clear the pair programming will probably not work and lead to conflict. –  Giorgio Jan 15 '13 at 10:55
add comment

6 Answers

up vote 26 down vote accepted

Assuming that the more experienced person in the pair has the temperament to mentor the other person, pairing someone with little experience in the language or the problem domain with an experienced person would facilitate knowledge transfer. The less experienced person would have a mentor to instruct them on the language, the domain, the application, and the best practices or conventions of the team.

There's an interesting summary on C2 wiki about knowledge transfer using pair programming. The more senior person, who was brought on to serve as the team mentor, learned a lot from the junior programmers and his knowledge even increased as a result of being paired with more junior, less experienced software developers. There are some other stories about expert programmers being pair with domain experts, as well.

share|improve this answer
    
Agreed. I have a junior in the team and pair programming dramatically increased the quality of his code. However, pair-reviewing his code was also very helpful. –  Sulthan Jan 15 '13 at 10:45
1  
You just have to be careful that the senior person isn't the driver 100% of the time. –  HLGEM Jan 15 '13 at 15:11
12  
@HLGEM I'd even argue that the less experienced person should be the driver most of the time, while the more experienced person is reviewing the code for defects and style or writing test cases against it. –  Thomas Owens Jan 15 '13 at 15:19
1  
I agree with @ThomasOwens; having the less experienced partner drive will bring up his/her 'experience' faster than any other method, while allowing them to share their own ideas and insights with the more senior partner. It won't take long before their proficiency levels are much closer. –  Eric King Jan 15 '13 at 15:25
1  
I wonder if this makes the senior dev more obliged to practice what they preach? –  JeffO May 1 '13 at 20:20
show 2 more comments

This is exactly the use case pair programming was made for: sharing experience between old beard and young grasshopper.

This is a two-way sharing: agile insects have much to teach to rheumatic brains.

share|improve this answer
1  
Though you'd probably consider me one, I lol'd on the 'rheumatic brains'... –  Marjan Venema Jan 15 '13 at 10:13
1  
I don’t think the term “user story” can be applied here. User stories describe business requirements for a software. –  Konrad Rudolph Jan 15 '13 at 11:37
    
Yeah, I think he means "use case". –  Jörg W Mittag Jan 15 '13 at 13:19
add comment

In my experience if both the programmers have low skill level it can be a problem. In that case there is often a tendency to try copy-paste programming. I think it can be a good idea not to pair two novice programmers together until they reach specific level determined by the team.

Otherwise pair programming can be a great idea assuming of course two guys are ready to share what they know. Not only is it a great way to keep everyone informed of the source code but also acts as good place for new ideas and discussions.

share|improve this answer
    
Low skill level devs are less likely to copy and paste when programming by themselves? This is usually what happens when nobody is watching. –  JeffO May 1 '13 at 20:22
add comment

When I got promoted to my current team I was the newbie in J2EE but I was the expert in the domain. My senior (the new team leader) was skilled in J2EE but not in the platform.

I think I learned more about Java2EE in these 4 months with pair programming than reading a book and the team leader learned about the platform as well.

The experience gap between the two is the key to pair programming imho.

share|improve this answer
2  
Agreed. I could imagine pair programming with myself, and I think it would be quite pointless. The gap is what creates the different perspectives relevant to making 4 eyes cover more scope in the vin diagram of possibilities. Two people with identical skills and experiences would see the same things as eachother and get no benefit. –  Jimmy Hoffa Jan 15 '13 at 17:36
add comment

I'll describe my experience and try to get some "strategy" out of it.

I've once pair-programmed with a complete non-programmer. He was expert on the subject matter of the software product we developed. On the contrary, I had no experience in the problem domain. And he also was my supervisor at the moment (I know this may sound strange :)

Major benefit of this methodology was that I had to explain implementation of many things from his knowledge domain, thus ensuring the exactness of implementation and his understanding of the process, which meant he understood why it took this time.

Another benefit is easy focus on the task, no distractions (ha-ha, imagine opening Twitter before the nose of your boss).

It was quite intimidating at times, however, since even a tea break became quite a "distraction from work" (not from his point of view; it was just inconvenient to ask for break and so on).

So, this isn't really a pair-programming since he pretty much couldn't review the code as it was typed in. However, it seemed to be a sane strategy (at least for some time). It ultimately worked at all because of relative simplicity of both development methodology (I mean, no complex software design techniques like OOP Patterns were involved) and subject matter. This would't work in case we had to develop a compiler I think. I believe it still could work in case non-programmer observer is participating in the process of development of small clearly defined pieces. Say, it's ok to have him watch programming of a function "compute the parameter X from Y and Z by given algorithm", but may be not so ok to have him watch overall system design process (meaning development of software architecture, i.e. hierarchy of classes, since it's too abstract).

I think it would work even better in case he would have some basic programmer skills, as I would't have to explain "what's an array is".

Hope it helps :)

share|improve this answer
    
It's good experienced explanation! –  Jojas Jan 16 '13 at 8:54
add comment

So long as the team members have respect for each other, pair programming can be beneficial regardless of the programmers' experience levels. Even if a junior programmer just spots a few syntax errors (which we all make!) before the more experienced programmer, that's still time saved in compiling code.

I also think it can open up a programer's attitude towards the capabilities of other members of their team, especially if they have an open mind and expect that everyone can teach you something.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.