Pair Programming: Junior/Junior pair
When it comes to Pair Programming the Junior/Junior pairing is considered the most likely to lead to disaster. The old joke being that if you pair two Junior Developers together then you'd better hope you have a revert function on your repository. But is this fair?
Certainly pairing two Junior Developers together means that you automatically lose the value of the experience and mentoring skills that you would get if there was a Senior Developer as part of the pair.
Assuming that we're working on an agile project, the biggest area of risk you have when doing this is the possibility that neither of the developers understood exactly what the story that they are implementing required and they end up going way down the wrong track and not managing to complete it in anywhere near the amount of time that was expected. Now clearly if this happens too many times then it could end up being a project risk, but if the project is being run well then I don't think that this is necessarily a problem.
Pairing two Junior Developers together gives them both the opportunity to gain confidence in their own ability. There is no longer a Senior person for them to defer to when there is a decision to be made so they have to step up and make the decision between them. This is a crucial part of our development as there are always decisions to be taken, trade offs to be made, and the ability to deal with this is crucial in agile teams.
It is also often the case that the Junior Developers who have just finished at ThoughtWorks University have been very well drilled in the art of pair programming and putting two of them together actually results in a very effective pair. They may not have the experience of other team members but their enthusiasm and lack of bad habits means they can be productive.
Having said that it is useful to provide a safety net of sorts for the pair so that they do not end up struggling (and I'm not even saying that that will happen).
Before starting on the story it is even more important that Tiny Tasks are created for the story being implemented. I find this an indispensable tool and if you ever look at my desk it is peppered with yellow stickies of tasks that I need to do to complete whatever I'm doing. The breaking down of tasks is brilliant for a Developer of any experience level, but is particularly useful here as a Junior pair may not have experience of solving a similar problem before and having a task list will help to keep them on track.
It is also useful to ensure that there is a more Senior person in the team (usually the Tech Lead) available to offer coaching/guidance if it is required by the pair. They may not need to intervene very often but the pair should feel that if they do run into problems that there is someone with more experience ready to help them out.
Overall I don't think this is a pairing combination that should be avoided, much to the contrary. The team should look for ways that they can help support a Junior/Junior pair and help them to develop their abilities so that them pairing together is not even an issue at all.
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.
Chris Johnston
14 Aug 08 at 7:54 am
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.
Pat
14 Aug 08 at 9:19 am
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.
Jeff Santini
14 Aug 08 at 11:04 am