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.