Remotely Pairing Up a New Developer to Your Project


While some short projects have a chance at keeping the team consistent, most projects don’t fall into this category. During the months, years, or even decades that the project chugs on for, a developer is very likely to be added or leave to work on another project and be replaced. How do you handle this transition period, especially when working remotely?
Until humans are wired up with Bluetooth transceivers for knowledge transfer, we can try pairing up in a more practical way with pair programming.
[[A surgeon is standing over a patient on a gurney.]] Patient: While you’re doing the surgery, can you also implant this in my arm?  Surgeon: A USB port? Man: Just wire it up to some nerves.  Surgeon: ... This won’t let your brain control USB devices, you know. Man: Sure -- I just want the hardware.  Man: The rest is software; I’m sure there will be a project to patch together support eventually. Surgeon: Ah -- you’re a Linux user, I see. Man: Yeah, how’d you know?
XKCD #644

Learning the project requirements, code architecture, setting up the development environment; all things that must be done before the developer can start being productive. A traditional approach is to hold a meeting where the developer is bombarded with everything about the project in a few hours. In a remote development environment, your communication options are less direct with using document sharing and video calls to convey the knowledge. The developer takes notes, but we often wonder what on earth we were thinking when we look back at them.
Messy handwritten notes on notebook paper.
After finally absorbing some of your notes, you realize that you have at least a dozen questions that you should have asked during the introduction call, but didn’t think of because of the amount of information that you were trying to absorb. Now you get to go chat with one of the developers again to get some stuff answered before you can be productive.
When I was in this situation on a remote development project, where another developer was joining the project I was working on, the developer had a great idea of doing some pair programming for the first week or so to speed up the transition process. We still had an initial call where some basic things about the project were discussed, but after that we went straight to the fun part, coding.
Two programmers sword fighting in the office while their code compiles.
Excerpt from XKCD #303
After they had their development environment mostly set up, we opened up a video call with screen sharing and worked out any remaining issues in the environment and got to work on the tasks that were initially assigned to me. Each of us took turns writing the code, with the other looking for errors, providing input on design, and answering questions.
This provided the developer starting out on the project with immediate feedback to any questions that would come up. Instead of having to instant message another developer and hope that they were online and had the knowledge to answer the question; or send a message to the project mailing list; they were immediately able to get the answer and become productive again.
In some cases the questions or issues they would run into were actually issues with the code or architecture that only somebody not familiar with the code would uncover. These issues could remain uncovered if it doesn’t seem worth bothering another developer with a seemingly minor question that may just be due to being new on the project. Since you have another developer right there, there’s no inconvenience in asking and the issue gets uncovered.
One of the downsides of working remotely in general is the social disconnect. This brief period of pair programming gives both developers a chance to get to know each other better outside of project team meetings. You can also learn all kinds of cool tidbits of information and tools from each other as you watch the other work in their development environment.
Unless your organization is structured around pair programming, you are probably going to operate more efficiently once the developers begin working on their own again. Therefore, within a week or so depending on the size of the project, the developers can part ways, both of them becoming productive. While it’s not exactly like having two developers doing the work of one, you certainly cannot expect the task to double in speed by assigning two developers to it.
Just as this process works for the process of adding a new developer onto the project, it can work for replacing a developer on a project, and maybe provide even more reward. If the schedules align and you have a decent-sized transition period, you can use that time to pair the developer who is leaving with the developer who will be joining. This has the added benefit of not only introducing the new developer to the project, but also of giving the developer who is leaving a chance to transfer their knowledge.
I often find that trying to type an email or document containing all this knowledge that needs to be transferred to be nearly impossible. There’s always something that gets left out that would have been remembered if you were going through the code with the new developer.
Your success will, of course, vary with this approach, but I found it to work very well in my particular remote development situation. The tools that we used were Google Hangouts for the voice and screen sharing, and Git for version control. Google Hangouts worked nicely because we had monitors of similar sizes; Google Hangouts does not have any zoom/scale options which would make it difficult to do this if the monitors were vastly different in size. It also helps to have a multi-monitor setup so that you can reference things while looking at the other developer’s screen.

+ more