Using Pairing While Onboarding Developers

You can use pairing for onboarding developers.

Don’t have time to waste on lengthy onboarding programs for developers? Consider the pairing method.


A lot of companies like to complain about learning curves, silos of knowledge, productivity, throughput, and wasting time while onboarding developers. Good news for them—paired programming solves a lot of these complaints, if not all of them.

When you’re onboarding new employees in software development, those new hires are essentially jumping into a giant vortex of unknowns. Each new hire probably has no idea what they’re doing in that project other than what they were told in their interview. Something like, “At Widget Software, we make the best software for widgets. We coded it in Widget++ language, and we need hungry people who want to get their hands dirty coding our new Widget Software features with us!”

That’s not really a lot to go on.

This kind of explanation doesn’t tell you about all the processes Widget Software uses to make their software, or all the nuances their software development team has adopted after years of hard learned lessons (e.g., how they like to work, who they look to for knowledge, workflows within workflows, etc.).

If your company onboards developers by bringing them in and assigning them low relevance tasks, expect those newbies to make a lot of mistakes, have a lot of questions, and add very little value.

With pairing, however, a junior developer is assigned to a senior developer in a partner capacity. The new, paired developer will come into a major project immediately, and, while they may not contribute anything at first, they have the advantage of seeing exactly what the daily workflow looks like by watching the senior dev operate. This means that the new developer is onboarded at a much higher level of efficacy, and is likely to be more engaged.

Pairing also allows for near instant data transmission between a new and older employee. Those nuances and custom built extensions can be seen immediately.

Pairing at Patriot Software

Five years ago, I was fresh out of school and paired with a senior developer. It helped a lot. At Patriot Software, we have many custom extensions and tools. When I first came on, we were using .Net 3.5, and there were a lot of things that it did not do, which required us to write custom stuff. In school, I learned how to use .Net 3.5, but a lot of what Patriot was using to streamline its operation was custom. Pairing me with a senior dev allowed me to learn all that custom stuff instead of figuring it out through trial and error, or, worse, reinventing the wheel and coding it myself.

Pairing also adds tremendous value to internships—for both the companies that hire them and the interns themselves. When I was in school, I’d hear how my classmates fared when on internships, and some would say, “I didn’t learn much because they didn’t let me work on much.” Pairing is a great long-term strategy to reap the business benefits of employee engagement.

Pairing allows you to get your intern’s hands dirty very quickly. Consequently, at Patriot, we don’t relegate interns to a corner with a hunk of menial software they can work on, without fear of them breaking our code. Instead, because we pair them, we’re able to give them access to working code for big projects they can proudly put on a resume—and that’s a pretty tremendous value. This paves the way for improved software developer motivation, and maybe even an increased feeling of long-term fulfillment.

The Bus Factor

Another major advantage of pairing is that it’s painless to implement. There is no retraining or down-cycle times. You can pair up a new developer with a senior developer tomorrow, if you want. But if you use something like Agile or Scrum instead, or change your software production in some other way, it can cause an exodus cycle or slow you down.  

Then there is “the bus factor” which is a really morbid way of highlighting information silos and bottlenecks in a company. Basically, the bus factor asks how many of your developers could get hit by a bus tomorrow without your software project screeching to a halt? If the answer is a low number, then your company is in trouble.

Clearly you want the bus factor for your company to be as high as possible, and one of the ways you can increase that number, without doing major onboarding overhauls, is to set up a pairing system. While pairing doesn’t allow you to make clones of your senior developers, it does allow you to catch more people up to speed faster than training and menial projects.

Downsides of Pairing

The pairing method of onboarding developers isn’t without it’s drawbacks. If you put a senior developer on a pairing team with a less seasoned dev, you should expect that senior dev’s productivity to dip since they’re teaching and coding at the same time. That said, the speed in which that new employee comes into his or her own should win that lost productivity back further down the road.

One final upside, even though this is the downsides section, is that pairing puts a proofreader right next to your senior dev. I’ve been working in code all my life and I know that, for all its technicality, writing code can sometimes be just like writing an English paper. You can easily make mistakes, commit typing errors, and put in misspelled instructions. It’s just the way our brains work; we’re thinking one thing but our fingers are putting down another with our subconscious paving over the mistakes.

When you have a paired partner with you, even if they aren’t directly sculpting code and building algorithms, they can help you spot errors that can, later on, take hours to hunt down.

 

, , , , ,

Comments are closed.