Pair programming is one of the best ways to learn programming, as collaborators can easily share their experiences and knowledge. This holds true when working with someone on similar or higher skill level, but can one really benefit from pairing with a novice developer?
Pairing session setup
When a less experienced person has control over keyboard during pairing session, then moving forward with a task is possible only when he understands what and how it needs to be done. That can only be achieved by explaining the expected behaviour from top to bottom, as well as what is the context, which files are relevant, and what are the connections between parts of the application. Not surprisingly, doing so is beneficial for both parties, as both get a better grasp of “what”, “how” and “why” something needs to be done. This is like having to consult rubber duck not only to fix a bug but every time.
No thought leaps
Pairing session in such setup prevents making thought leaps. When a person feels comfortable in a given language/framework/library, it’s common to skip obvious steps in solution designing and going straight to the solution. When pairing it’s impossible so you have to make logical steps one after another and cannot cut corners.
Another good thing is having better commits. When taking baby steps, it is natural to “save” the changes every time any part of the solution is completed. Committing often and after logical steps is especially important if the apprentice has freedom in coming up with his implementation, as everything can happen and his further explorations might break already done parts of the solution.
It’s easier to make simpler solutions
Pair programming with novice favours making KISS solutions. It’s required to go for simpler solutions unless you want to explain something unnecessarily complicated and waste both of your time. Obviously, in many cases, this has a positive effect on the implemented feature and the application maintainability. It’s the case because if someone with little experience understands the way given thing is done, then it should not be a challenge for other developers or future you.
What were the costs
Even if you find a pretty clever guy, still, there is a significant development slowdown, sometimes even blocking the entire process altogether. You need to explain things, watch him use the IDE in not the most optimal way, sometimes dig together into depths of documentation to educate both of you. This might be very enlightening and fun, but obviously not when deadlines are on the horizon. So in order to really take advantage of such collaboration consider times when your team is not under time pressure.
Overall impact for the company
When thinking about the indubitable profits of pair programming for the company, you definitely should consider that by inviting promising students/high schoolers to your company you get access to local talents before they get captured by competitors. Introducing them to the work environment, the company atmosphere, and getting the “first blood” in the programming world will influence their decision to join your forces after graduation. When they do, continuing with pairing is even more beneficial. You will be slowed down to some degree at the moment of pairing, but he will be faster multiple times from now on and will capitalize on that shot of knowledge/skill. So pair programming is blazing fast way of getting juniors up and running on commercial projects.
Despite the temporary impact on your personal development speed, working with someone less experienced brings lots of advantages to everyone. App implementation is simpler and less buggy. You train patience and communication skills. A company is more likely to attract young local talents, then deploy them faster on the projects. For me, this sounds like a good deal. However, if you think differently, let me know in the comments 🙂