Onboard New Developers Faster With This Guide
Tags: management, onboarding, development, teambuilding
Published: 2021-10-14 14:02:12

---
title: Onboard New Developers Faster With This Guide
published: true
description: Are you tired of having to hold every new developer’s hand and watching them struggle to get up to speed with your team? Use this guide to streamline and improve the onboarding process for new teammates and yourself alike.
tags: management,onboarding,development,teambuilding 
canonical_url: https://builtin.com/software-engineering-perspectives/developer-onboarding
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2lpoqp2xq4k0maqazr58.jpg
---

Are you tired of having to hold every new developer’s hand and watching them struggle to get up to speed with your team?

[Onboarding new teammates](https://www.method.com/insights/company-onboarding-from-a-distance/) should be fun and easy, for everyone involved.

I've lost track of how many developers I've onboarded to my engineering teams. Though important, this process is very often a pain point that sucks time away from my day-to-day responsibilities. Or at least that was the case until I created the “Zero to Deployed” guide for our team. This guide has streamlined the onboarding process so that both existing and new team members can complete necessary training and get up to speed as quickly as possible. That way, onboarding transforms from a drain on resources to a streamlined process that allows everyone to focus on their primary responsibilities in a timely fashion.


## The "Zero To Deployed" Guide

The “Zero to Deployed” guide walks a new dev through every single, tiny step from the moment they open their laptop until the moment they deploy a feature. We write it with deep detail so that a junior developer can follow the steps without asking for help.

We immediately saw this pay off — our onboarding time (for us, this spans the moment new hires open their laptops until the moment they create a PR) went from one to two weeks down to two to three days. The process also involved significantly less hands-on assistance from team leads. We then broadened the guide to apply to all engineering teams across our organization, and the benefits immediately scaled.

Below, you can find a rough outline of what we include, how detailed we get, and you can use this as a template to develop your own version.


### Beyond The "Zero To Deployed" Guide

Before we look at the guide itself, however, we need to consider a few important ancillary documents. After all, there's more to your codebase than just the setup. So, we include some other complementing documents with the guide itself:



* The Core Concepts Onboarding
* Rules and Guidelines

The **Core Concepts Onboarding** is a high-level overview of the tools in your product and the main components of the applications. The aim with this document is not to be exhaustive, but just to give the new team member enough context and guidance to be productive. For example, it might include what a fully-baked React Component usually looks like, how our app uses some crucial library, how our app interacts with other apps/services, and the main features of our application (or suite of applications) to name a few items.

The **Rules and Guidelines** set the practices and standards for the codebase, acting as a how-to guide for the code that we write. For example, this document details our git management strategy and merging rules, our rules around redux patterns, [unit testing guidelines](https://www.method.com/insights/writing-user-focused-tests-with-react-testing-library/), code style rules, and [things to look out for during code review](https://prowe214.medium.com/the-code-review-checklist-3b538194786b).

These can all be compiled into one document or spread out over many smaller ones. The important thing is that the guide is easy to reference and clearly teaches your new teammates how to write code in your repository. It also helps if you can create links directly to certain content in these documents (with header anchors or separate pages) so you can easily share relevant information later during code reviews.


### Maintaining the Guide

Every time we onboard a new developer, we also give them the power to edit the guide. As time goes on, steps change, and it may come to contain outdated information or be missing new material. The new team member is responsible for finding the new information and updating the guide so that future developers don't run into this same roadblock. This is usually the only time that managers are required for assistance in order to find that information, and becomes an increasingly rare occurrence as the guide matures.


## An Example "Zero To Deployed" Guide

Here's a high-level example of our Zero To Deployed Guide, so you can understand and create one for your own team.

Note: In our real guide, each bullet point includes detailed commands, instructions, and examples for successfully performing that step.


### Dev Setup

Figuring out the best environment for developing our app usually matures with time, as we discover which tools most effectively help our development process.  We can fast-forward this discovery experience for our new teammates by explicitly walking them through setting up every tool that has been making us productive for so long.



* What logging into your computer for the first time involves
    * Step-by-step instructions for getting logged in, and what applications you need to log into
* (If needed) How to request access permissions for software/environments
* When you open your computer, install &lt;these things>, using &lt;these commands>
    * Homebrew, git, etc.
    * VSCode, Postman, Chrome, etc.
        * Required and recommended extensions for each app
* Clone the repo, then install dependencies
    * Step-by-step guide for cloning, setting up git credentials, etc.
* How to Run the app
    * Include main flows for them to experience to validate that their application is running smoothly


### Building a Feature

Every development team has a different process for taking a feature from ticket to merged code.  Here, we set up a step-by-step walkthrough of this process, and what to expect as they reach each step.



* How to Create a feature branch
    * Typical root branch, branch naming
* How to [Test the feature](https://www.method.com/insights/a-guide-for-software-quality-assurance/)
    * Unit testing, manual testing, dependency testing
* How to Submit a PR
    * Rules around titles, descriptions, and build pipelines
    * What to expect during code review
* How QA Tests your feature
    * This gives context on what kind of feedback they'll be receiving from QA
* How to Merge the PR
* How to deploy
* How to validate a deployment


### Supporting Guides for our organization

Our supporting guides are our source of truth for all practices and patterns.  We make these as easy to access as we can, so that links can be shared directly to the relevant content.  Our developers continuously update these guides as they come across new issues or develop new patterns.



* Resources
    * External links for training modules
    * Important links within the organization (Confluence, JIRA, etc)
* React Practices (Core Concepts)
    * There are lots of ways to build React applications, here's our pattern to follow
* Typescript Practices (Core Concepts)
    * Typescript is still new to a lot of people and documentation is overwhelming. We include the important parts for our applications
* Styling React components (Core Concepts)
    * [How we use libraries](https://www.method.com/insights/when-third-party-libraries-add-technical-debt/) and reuse component styles
* Unit Testing Practices (Core Concepts)
    * What to test for, how to test for it, and the most-used methods
* Redux Practices (Core Concepts)
    * Defining our patterns around redux, and giving examples of the most common cases
* Git and Pull Request Practices
    * Rules around branch naming, PR rules, and code review guidelines

At [Method](https://www.method.com/), we design, strategize, and build all types of software for our clients. Beyond just delivering a quality product, our duty is to teach our clients practices to leave them stronger as an organization. This is one that has proved extremely successful.