Onboarding? Join me!

Are you new to a project? Is your team getting a new member? How should you manage it? Well… I may have an answer to that.

I’m sure everyone has experienced it at some point in their lives. Being the new kid on the block is always hard, no matter your seniority. Whether it’s reading some documentation or having someone to explain to you how things work for a whole afternoon, there’s never enough knowledge transfer to start writing code all by yourself. One approach I’ve experienced first hand is to take really easy tasks (like minor bugs) at first and get more confidence and knowledge with time, but that doesn’t prevent you from needing help very often and/or finding yourself browsing cluelessly through the code.

So what can you do? For me, pairing is the answer.

Pair Programming (or just "pairing" as I’m used to calling it) is a software development technique in which two developers work at the same time on the same computer. The results are great: from a technical standpoint, the software quality improves, reducing bugs and enhancing the code cleanliness, while the productivity, against common reasoning, doesn’t lower a bit. On the other hand, from the team standpoint, they improve their relationships and also the general knowledge of the different parts of the project. Moreover, sometimes it’s used by expert programmers to teach less experienced ones (seniors to juniors, you could say).

But what I’ve found out and would want to focus on here is that it’s a fantastic tool to introduce new developers to big projects. It allows the team to make a great knowledge transfer to the new member, without affecting the project pace.

Basically all what’s needed is a mid-experienced dev in the project, the new one and almost any feature ready to be worked on!

At first, it’s quite obvious that the experienced member is expected to be the one in charge, taking decisions on what to do next and how. But as the new one gets more into the code, the roles are expected to change, first by giving him/her the opportunity to write the code, and then by taking bigger decisions until the experienced dev takes the role of almost a mere consultor. The process evolves through time.

Being the new developer allows you to get into the project’s domain really fast, gaining understanding of its model and workflows. But it also teaches you about its dependencies, technologies, coding practices (and other practices in general) and everything needed to work on the project in a daily basis.

But as the experienced developer you also get many benefits. First, you get another pair of eyes to reinforce your work if the task is not very complex, and a full dev to help you when things get complicated! And ultimately, explaining and teaching always opens up new perspectives and deeper understanding on the subject (rubber ducking, anyone?) and even more if your partner has questions you have never even thought of!

The only downside is that it’s obviously more time-consuming to teach and code rather than just coding, so it may slow down the experienced dev work a bit at first, but as it pays off in the long run, I can assure you it’s an investment well worth making.

Wasn’t I able to convince you? Just try it out! Pick a partner, any story you like and let the knowledge flow. I’m convinced of its results after experiencing it, so I’ll let you do the same ;)