Comments on: Pair Programming: Junior/Junior pair http://www.markhneedham.com/blog/2008/08/13/pair-programming-juniorjunior-pair/ Thoughts on Software Development Thu, 11 Mar 2010 17:19:04 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: Jeff Santini http://www.markhneedham.com/blog/2008/08/13/pair-programming-juniorjunior-pair/comment-page-1/#comment-26 Jeff Santini Thu, 14 Aug 2008 10:04:24 +0000 http://www.markhneedham.com/blog/?p=102#comment-26 Re: Chris Johnson I think the issue you highlighted were not junior/junior pair problems, but team problems. In your scenarios the pair members were not the source of the issue. It was outsiders who had inappropriate expectations. Re: The Post The whole ideas of not putting juniors with juniors smells a bit of ego and control to me. Not to say that it can't go wrong, but I if we are relating anecdotes, I have seen senior/seniors go into a corner and launch a new framework initiative that is a waste to the project. Any pairing can go right, and, I believe, any pairing can go wrong. It is less about your IT knowledge than it is about your pairing knowledge. When to seek help, awareness of your progress towards a solution, awareness of your pairs commitment and capabilities. These are issues of your pairing skills as opposed to your dev skills. As long as you know when to seek help and as long as help is available from outside the pair, you have the tools for success. P.S. Hi Mark. Re: Chris Johnson
I think the issue you highlighted were not junior/junior pair problems, but team problems. In your scenarios the pair members were not the source of the issue. It was outsiders who had inappropriate expectations.

Re: The Post
The whole ideas of not putting juniors with juniors smells a bit of ego and control to me.

Not to say that it can't go wrong, but I if we are relating anecdotes, I have seen senior/seniors go into a corner and launch a new framework initiative that is a waste to the project. Any pairing can go right, and, I believe, any pairing can go wrong. It is less about your IT knowledge than it is about your pairing knowledge. When to seek help, awareness of your progress towards a solution, awareness of your pairs commitment and capabilities. These are issues of your pairing skills as opposed to your dev skills. As long as you know when to seek help and as long as help is available from outside the pair, you have the tools for success.

P.S. Hi Mark.

]]> By: Pat http://www.markhneedham.com/blog/2008/08/13/pair-programming-juniorjunior-pair/comment-page-1/#comment-24 Pat Thu, 14 Aug 2008 08:19:11 +0000 http://www.markhneedham.com/blog/?p=102#comment-24 I'd definitely recommend reading the Pair Programming Illuminated book. It's covers some scenarios like this and how to deal with them more effectively. I'd definitely recommend reading the Pair Programming Illuminated book. It's covers some scenarios like this and how to deal with them more effectively.

]]> By: Chris Johnston http://www.markhneedham.com/blog/2008/08/13/pair-programming-juniorjunior-pair/comment-page-1/#comment-22 Chris Johnston Thu, 14 Aug 2008 06:54:26 +0000 http://www.markhneedham.com/blog/?p=102#comment-22 One thing I would add to your post, being a junior programmer who has done a little but of junior/junior pairing is that any team who is going to do this must also do two things: 1. It should have a senior dev / Tech lead who picks out the stories for the pair to work on, or at the very least approves the stories that they pick. I completely agree that putting two junior devs together on the right story can be a huge boost to their confidence levels. However, putting them together on the wrong story can be hugely demoralising as the pair become more and more frustrated with the inability to solve the problem. Avoiding this requires a senior dev who is able to suggest/approve good stories for the pair and who is patent and guiding when they get into trouble. I have been on a few projects where junior devs were expected to be able to solve the same problems as senior devs and when they could not, the senior devs simply got frustrated with the juniors. This is a good way of having your junior devs leave. 2. The team as a whole must be willing to allow the junior pair, and all junior devs, to make mistakes. They need the space to mess up, implement things poorly, and say and do the wrong things. This is the best way for them to learn. However, too many teams expect juniors to work and produce at the level of seniors and don't give them space to mess up. Nor do they have the patience to properly guide and nurture junior devs. Another thing I would add is that teams who do this need to setup some kind of mechanism through which they provide constant feedback to the junior/junior pairs. There needs to be touch points that tell the devs whether they are headed in the right direction and what they can improve on. I completely agree with what you have written, but wonder if the average team is capable of following your advice. One thing I would add to your post, being a junior programmer who has done a little but of junior/junior pairing is that any team who is going to do this must also do two things:

1. It should have a senior dev / Tech lead who picks out the stories for the pair to work on, or at the very least approves the stories that they pick.

I completely agree that putting two junior devs together on the right story can be a huge boost to their confidence levels. However, putting them together on the wrong story can be hugely demoralising as the pair become more and more frustrated with the inability to solve the problem.

Avoiding this requires a senior dev who is able to suggest/approve good stories for the pair and who is patent and guiding when they get into trouble.

I have been on a few projects where junior devs were expected to be able to solve the same problems as senior devs and when they could not, the senior devs simply got frustrated with the juniors. This is a good way of having your junior devs leave.

2. The team as a whole must be willing to allow the junior pair, and all junior devs, to make mistakes. They need the space to mess up, implement things poorly, and say and do the wrong things. This is the best way for them to learn. However, too many teams expect juniors to work and produce at the level of seniors and don't give them space to mess up. Nor do they have the patience to properly guide and nurture junior devs.

Another thing I would add is that teams who do this need to setup some kind of mechanism through which they provide constant feedback to the junior/junior pairs. There needs to be touch points that tell the devs whether they are headed in the right direction and what they can improve on.

I completely agree with what you have written, but wonder if the average team is capable of following your advice.

]]>