31

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?

Ixrec
  • 27,621
  • 15
  • 80
  • 87
Sakares
  • 421
  • 5
  • 8
  • 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
  • But, if done as you suggest,it can be a tremendous learning opportunity. – Mawg says reinstate Monica Jun 02 '15 at 10:09

6 Answers6

28

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 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
  • Agreed, pair-reviewing their code is very useful to do – Sakares Jan 15 '13 at 14:06
  • 2
    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
  • 13
    @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
  • @ThomasOwens, I agree, I just know that many seniors get impatient with the junior driving because it takes longer than if he does it himself, so I just wanted to point this out as a possible problem. – HLGEM Jan 15 '13 at 15:55
  • 1
    I wonder if this makes the senior dev more obliged to practice what they preach? – JeffO May 01 '13 at 20:20
17

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.

mouviciel
  • 15,473
  • 1
  • 37
  • 64
10

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.

dierre
  • 211
  • 2
  • 6
  • 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
5

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

Michael Pankov
  • 568
  • 1
  • 5
  • 15
2

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
minusSeven
  • 723
  • 1
  • 7
  • 17
  • 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 01 '13 at 20:22
1

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.

TheDarkKnight
  • 486
  • 3
  • 6