Onboarding New Developers

01 August 2017

Photo: Unsplash

Over the past few weeks, we have had two new developers join the Open Energy Market team. It’s always enjoyable when new developers start. Two within a couple of weeks has meant some parallel discussions and observations.

I see it as vitally important how you onboard any employee to your company. How you welcome them on that first day sets a tone that can sometimes be hard to change later on. Remote developers are especially important. You want them to feel included and productive as soon as possible.

First things first. Once a developer accepts an offer I order a standard spec laptop and get it delivered to their home. A standard spec at Open Energy Market is quad-core, SSD and 32gb DDR4 ram. The developer can request a certain screen size but that is the base specification I insist they have. I also sign them up with a Bizspark licence and let them get on with getting their basic set up going.

By their first day, they have access to all the core applications and systems they need to do their job. This includes Slack, Dropbox and GSuite amongst others. It does not include hosted services such as AWS or Azure. If it requires training or explanation then we arrange that for within the first couple of days. Talking of Slack, always introduce any new member of the team on Slack and encourage everyone to say hi.

Once the introductions are over it’s time to get a development environment up and running. At present we have it well documented. Following the instructions step by step will see a developer up and running in a couple of hours.

For an employees first week I try to schedule time with the Management team. There is only the 4 of us but getting each of us to welcome the employee makes them feel as valued as they are. It helps build an understanding of everyone’s roles and how the company fits together.

From the second day, the developer has 2 main objectives. One, find a mechanism for learning the applications codebase. Two, put in place a change within the first 2-week sprint that we work to.

Point one, familiarising yourself with a new codebase is a personal thing. Different developers each have their own ways. Some like to have a range of issues to fix which provides broad exposure to the codebase. This is a good way to go. On occasion, I have found that due to a lack of context, the developers make incorrect assumptions and changes. Another approach which we tend to make all new developers do is to answer a questionnaire. The questionnaire is specific to us and was suggested by our very first developer when they joined. It has a range of questions relating to security, frameworks, logic, libraries amongst other things. This works really well. On average I find that besides fixing a small issue or making a small improvement it doesn’t take more than 7 days for the developers to complete it. When they have we go through their answers and fill in any immediate gaps.

Point two, getting the developer to make a visible change within the first sprint makes them feel like they immediately add value to the team. There is nothing worse ( I know) than spending 3 months learning a codebase and starting to make changes before anyone benefits from my work. I want the developers to be committing valid changes as soon as they are comfortable to.

I’d be interested to discuss how you onbaord developers via twitter or email.