/ #productivity 

How to introduce a new developer to a project

post photo by pexels

Introduction

Often, there is a need to introduce a new developer to the team for a specific project. This on-boarding process is never easy and sometimes tends to be painful for the new member and frustrating for the team, which has to keep working on the already defined tasks without a big impact on their productivity.

Of course, this process differs from team to team and is proportional to the seniority level of the new team member, as well as the time they have been working at the company.

I will try to keep the following guide as abstract as possible, to accommodate most cases. Keep in mind though to tailor the recommendations to fit your team’s needs and post your thoughts in the comments!

This guide assumes a typical 8-hour workday. It is further divided into subsections, with ideas about what to do during each time of the day. Feel free to update it according to the habits and ceremonies of your team, to maximize value.

The 2-day plan

Day 1

This is the first day that the new team member will start working along with your team. It is a very special day, of course! You don’t want to stress them or to make them feel lost, even though it is highly likely that they will feel overwhelmed anyway. Try to be as cool as possible and not throw deadlines and project reports to their face. Your job is to make them feel welcome and productive.

Day 1 - Morning:

  1. A short overview of what the business does (an hour, tops) - understanding how the company makes money is important. If the new developer is in the company already, then a brief introduction of the project is in order, along with the business side - how the project works and how the client makes revenue.

  2. A short overview of the high-level architecture (no more than a couple of hours). If the team has already decided upon frameworks, Database technologies, 3rd party libraries, or external APIs, this is something that should be communicated in time.

  3. A learning plan for project-specific technologies. The new developer needs to feel not only that they have the time required to get up to speed with all the languages and the frameworks, but also that there is no time to slack off, or feel unproductive.

Day 1 - Afternoon:

  1. Update on the learning plan; Questions, answers, and a small update of what has been taught so far. The goal of this is that the new developer does not waste time researching everything about the new language/framework, but only this 20% that will get them going and become productive, according to the Pareto Principle

  2. Learning how to set up a project in the new language/framework. They will need to do that anyway, so it will come in handy.

Day 2

During this day, the new team member should get cracking with real project tasks. However, this doesn’t mean that the learning stops. On the contrary, the learning has now a supplementary role, and it becomes less important as the tasks progress and the developer feels more comfortable.

Day 2 - Morning:

  1. Project set up and initialization. If the project has an existing codebase, the new developer will need to clone it to their machine, set it up, and get it to compile/build/run (depends on the framework). This is usually not easy, and every other developer on the team needs to pay attention here.
    Often, this process reveals a lack of proper documentation of the project. Developers sometimes assume things, especially for the installation/set-up procedure of a project. So this is an excellent opportunity to revamp the documentation of the project and make sure that there are no assumptions.

  2. A specific task which gets them familiar with just one or two files in the codebase, done with one of the more experienced programmers sitting with them to help 1:1. It is crucial for a new developer not to feel alone on a task.
    The best strategy is to assign them to a task that only exposes them to as few files as possible so that they don’t feel lost.

Day 2 - Afternoon:

  1. A couple of short specific tasks with an experienced programmer dedicated to helping a “small group of starters” (typically 2–3).

  2. Flying solo on a small task, but knowing that they can ask for help [this never stops.

  3. Repeat, with increasingly larger tasks, covering more of the codebase.

At this point, the new developer should already feel comfortable and productive. However, remember that as the difficulty of the tasks increase, they may feel overwhelmed again, and that’s usually when the Impostor syndrome occurs.
So, it becomes obvious that the new team member should feel free to ask any questions, no matter how “stupid” or “obvious” they may seem.

What to do now - Action points

After you have read this guide, it’s time to get cracking and create your personalized on-boarding plan! Of course, your organization has its own rules and pain points, and the team your a member of may benefit from different situations and habits.

After all, it’s your responsibility to create an on-boarding guide that best fits and serves your team’s needs.

So, go ahead and don’t be afraid to spend some time writing down ideas and situations that fou and your team found * *difficult** and unsustainable in the past. Then, write how these problems could be alleviated, by applying the 2-day on-boarding plan, and don’t be afraid to try your own plan (we only get better by trial and error!)

Last thoughts

To conclude, adding a new member to a software team is not an easy task. Sometimes we forget how important the onboarding process can be, resulting in poor estimates (as the on-boarding is hugely underestimated), Impostor syndromes, and confusion for the entire team. Having a solid and effective on-boarding plan is crucial as it ensures both productivity and good morale for the entire team.

Further readings