New Developer Onboarding

September 10, 2019
Engineering

Why Onboarding Is Important

The onboarding process technically begins with hiring, but it happens mainly during a person’s first few days at a company. Discussions about onboarding tend to revolve around new hires, for obvious reasons, but the process is important for everyone: while the new developer learns the most important aspects of team and company culture, the team has an opportunity to learn new ideas from a fresh pair of eyes. Additionally, onboarding gives team members a chance to mentor, which can make a difference later in their careers. We find that a smooth onboarding process not only allows our developers to get up to speed but also gives them a chance to contribute to our most important systems and projects from the very first day.

How Onboarding Works

We onboard junior and senior developers the same way. (We don’t call junior developers interns because they work on the same projects as the rest of their team). The first day is as much about learning how our deploy process works as it is about any feature development. Any new person joining our team–no matter their level of experience–deploys a change to production on their very first day. This method, used by companies like Hootsuite, Code As Craft, and Big Nerd Ranch, is popular because frequent, rapid, small deploys are great contributors to engineering success—they make developers, product owners, and maintainers happy. For the new recruit, it’s hugely satisfying to see a change in front of customers immediately.

Computer Setup

To start, everyone gets a new computer from factory settings on which they have admin rights. The first couple of hours are mostly about setting up mail and GitHub access and getting acquainted with the machine. 

Pushing a Change to Production on Your First Day

There’s no better motivator than seeing customers immediately benefit from a change you made. This change may be small, and someone will be guiding you through it, but it will be a change nonetheless, and it will be yours. By pushing a change to production from the start, we show our developers that we're serious about them making an impact. 

The developer workflow will be familiar to anyone who's worked on an open-source project—branch, change, pull request (PR), review—with a few testing steps that make it easy for developers to see their changes in environments increasingly similar to production:

  • Read the task
  • Set up local environment, make the change and test it
  • Deploy to a staging machine, test and make changes as necessary
  • Present the change as a PR, which is then reviewed and eventually approved by a colleague; because the initial changes are small, these reviews are generally quick
  • Merge approved PR to master; wait for CI to build the package.
  • Notify the site reliability engineers (SRE) of the impending deploy, link the PR, and get approval to continue
  • Deploy to a canary and test changes
  • Deploy to the rest of production
  • Celebrate!

For the first task, the change is usually something very small but visible (anything from fixing a typo, to adding explanatory text, to fixing an annoying UI glitch), so that you don’t have to iterate over the steps too many times. By the end of the day, you will have done all of the most intimidating tasks a developer faces in a new position, regardless of prior experience. We've found this method prepares new hires to take on large tasks relatively quickly.

This doesn’t just happen, of course. These changes work because we put a lot of effort into building and maintaining systems and processes. For every change a new developer makes:

  • Our local and staging development environments must be up to date and functional
  • Our build/CI system needs to work seamlessly 
  • We must have tests for everything that runs automatically and in good time
  • Our deploy tools have to work seamlessly (we use a chat-ops bot in Slack)
  • Our teams, both developers and SRE, need to be attentive and available to support the process.

It looks like a lot of work, but everything that goes into making the first-day deploy happen also ensures that the day-to-day business runs as smoothly as possible.

Try Hosted Graphite now!

Get Hosted Graphite free for 14 days. No credit card required.

Get Started

Heather Wiencko

Software Engineering Manager at Hosted Graphite.

Related Posts

See why thousands of engineers trust Hosted Graphite with their monitoring

START A FREE TRIAL