Pair Programming as a Mentoring Tool

I’ve been using various pair programming techniques for many years to collaborate with team members, both in-person and remotely. In almost all those situations, though, I was working closely with someone well skilled in the art, or at least having a few years of practice in college or in the workplace. Recently, I started working with clients/partners as a mentor. Most of my clients have historically asked me to deliver a product, but they don’t want to know how it works. As I’ve gone further down the dark path working intimately with start-up companies, I’ve encountered more and more people who are not only interested in building a great concept, but also want to learn as much as they can in the process. In these unique and somewhat rare circumstances, I am finding many of the same pair programming techniques I used for remote collaboration and code review are well-suited to this situation.

One of the concerns I’ve been finding as I read more about pair programming is the challenge presented by a substantial difference in the skill levels of the participants. In many cases, if one person is much more experienced than the other, the tendency appears to be to have the expert building while the novice watches. This is good for productivity in the short term, but does little to expand the novice’s skill set. I find the best strategy to avoiding this is to swap people, allowing the expert to guide the novice without actually typing anything. This can be tedious, as it can come down to the expert verbally expressing command line statements. Still, I think this sort of scenario does much more to exercise the novice’s creativity and problem-solving abilities. Plus, it can’t hurt that the less experienced person does all the typing. That way, there’s a tactile component, so muscle memory can help form the foundation connections that are essential to the learning process.

As I watch people interacting with their computer, I can see patterns in their behavior, mostly subtle things like typing filenames out manually instead of using tab completion shortcuts. Often, these situations are presentations of missing information in the active consciousness of the person. When I see them, I can offer suggestions that save time and frustration in the long term. Tab completion is a big one. That, and effective use of navigation hotkeys. Even after a dozen times in some cases, folks still hunt for files by scrolling through a tree, when they could use cmd-T to find a file by name. I’ll say “let’s look at the routes file” and they’ll immediately start scrolling through looking for the config directory that contains the routes.rb file, and I’ll smile. After 10-15sec of watching their bewildered scanning, I’ll say “since you know the name of the file you want to find, isn’t it easier to use the hotkey?” and they almost always say “oh, right… duh” and then the file immediately pops up on the screen.

My goal is to teach them something useful, something that can save them time in the future. I’d probably be amazed at the number of keystrokes I have avoided by using shortcuts and hotkeys, over the total sum of my career. I imagine it’s a very big number.

So far, it’s going really well. It’s exhausting, and really after two hours or so, it’s easy to lose focus, but I’m finding it extremely rewarding. We’ve been able to strike a great balance. I teach some of the basics as we build the most common components in an app. Once we hit the point where the bulk of the remaining work is repeating efforts from the first phase, we switch roles, and I build and talk about what I’m doing while they watch. In some cases, it makes sense to even skip the pairing entirely, especially when the driver isn’t doing anything that the observer/navigator hasn’t already seen. Also, in cases where the subject matter is too advanced for the client to grasp or more detail than they want/need to know, pairing makes less sense. Finally, since this is a for-profit endeavor where I’m billing hourly, it’s more cost effective for the client to be involved less, as the progress tends to be 3-5x slower with the client driving and 1.5-2x slower with the client observing.