Pair programming has been a known and applied method for a long time. I know that it has more than one purpose and practice, but I want to say some things about an expert and a novice working together.
For a long time, I went to the dental clinic for braces treatment, and after my treatment was over, I had surgeries two times (no worries, I’m fine). Sometimes there was more than one doctor at my appointments. One was relatively more experienced than the other and would generally instruct the less experienced to do what they would have done. The novice one was following the instructions without asking any questions because there was an actual patient, and they were trying to imitate the expert one as much as possible. After a while, the novice was now taking care of the appointments alone.
Another thing I observed was that not every novice doctor always matched with the same expert. I think that is an essential detail because it explains that experts also go through similar processes.
In the projects I’m working on, there are code reviews, we’re writing documentation, and we update it as new questions come in from novices. Also, I don’t miss to say to the novices that they can ask me any questions, then I tell them that I’ll answer when I’m available, but none of these solves the main problem. So I realized too late the importance of pair programming.
To elaborate on the main problem, let’s think about the topic using the same metaphor: Consider there’s a novice doctor who cares for you for the appointment, and there’s no one else that helps them. They can’t make the patient wait for asking a question to an expert doctor and can’t record the operation during the treatment and ask for a talented doctor to review how they do the treatment later. So the patient comes to the appointment, they do what they should do, and the patient goes out when the doctor completes their work.
To speed up the adaptation of a novice to the team and save time for other friends in the team, it may be a good idea to give them a critical job that will directly affect the quality of the production, directing them verbally or in writing. So the novice will implement the workflow a few times under the observation of an expert, and the expert will let them take a risk.
Let’s move on to the second important issue, the case of experts and novices randomly matched every time. There are a few key benefits this provides:
The novice receives training from multiple experts instead of a single expert. If there is any inconsistency between the information received by the experts, the novice will object and warn the expert.
An expert will resolve this inconsistency by talking with other experts if necessary and will inform the final decision.
Both the novices will meet with multiple experts, and the experts will contact multiple novices. Thus, coworkers will establish relationships with each other one through their positions, not personally.
I find the benefit mentioned in the last item very important. It is crucial that the projects are independent of the person and that the positions are fixed and maintained by different employees. If a developer can quit a project quickly, the project is independent of the persons. Therefore, we can consider it the success of the developers of the project. The case is also good for the developer because they will strike a snag-less when changing their team or project.
The Cost of Making Busy the Expert
In pair programming, the time spent by two people doing the same job will be multiplied by two. However, it can be misleading to calculate the person/time with such straightforward logic. This cost is bearable in the long run to reduce the time it takes for a novice to get used to the job and take on responsibility.
The key here is to keep an expert busy for a maximum of one or two hours a week, ensure that each expert takes responsibility, and share tasks fairly.
The second point to reduce the cost is that the job selected for pair programming has to be the expert’s job, not the novice’s. In other words, the expert will give one of their tasks to the novice, observing them if they completed the task as well. In this case, the only cost for the expert will be wasting some time by giving the job to a novice instead of quickly doing it independently. But, as I said before, this cost is bearable in the long run.
As I wondered and researched this subject, I realized that it was a little more complicated subject than I had anticipated. Therefore, without prolonging this article, I would like to inform the reader by sharing some resources.
Awesome Pair Programming: Awesome pages are famous; they even made a page of pair programming. I looked at this before Wikipedia.
Pair Programming (Wikipedia): General information about pair programming here. The pair programming method I mentioned is an expert & novice.
Pair Programming (Martin Fowler): If you’re wondering what Martin Fowler thinks about pair programming, yes, he has an article about it too. Pretty detailed post.
Pair Programming (The Beauty and Joy of Computing): A short article explaining how (not) to pair programming.
Pair Programming (Laurie Williams - NC State University): I haven’t read all of them, but those curious about the short history of pair programming can take a look. I especially recommend The Mythical Man-Month book.
Pair Programming (Laurie Williams - PennState): Yet another academic article with advice on pair programming.