Inspired by Increment magazine’s “What it’s like to be a developer at” series, here’s my take on what it’s like to be an engineer at Gusto. Our high-level engineering principles have stayed the same, but we have updated a lot of the tools we mentioned in our first post about “Our Development Flow.”

What are the most common tools that developers use at Gusto?
We use a range of tools across all our teams. Here are some of the popular ones:

  • Docker
  • Slack
  • IDEs (RubyMine, Sublime, Atom)
  • Confluence
  • Project tracking (Jira, Pivotal Tracker)
  • Git, GitHub
  • Jenkins

Coffee is my most important tool.

Which languages do developers code in?
We use Ruby for the backend and React on the frontend. Some of our services use Go, and the data team uses Python.

What is the development process (the lifecycle of a piece of committed code) like?
We like to wear many hats at Gusto, so part of the development process is to investigate, write out expectations, and prioritize stories. After stories have been broken down into manageable pieces, we’ll go through the typical flow of writing code that fulfills the requirements, writing automated tests, and submitting a pull request (PR) for review.

Pair programming is part of our engineering culture and it’s really versatile at Gusto. Scheduling meetings to pair is common and there are a variety of reasons such as onboarding a new member, fixing an urgent production issue, or even casually diving into another team’s new feature.

We have dedicated pairing stations around the office so it’s easy to find a spot to plug in and share your screen. Also, not being present in the office doesn’t stop us from pairing! We happily pair through Slack calls when necessary.


Gusto Fast Facts

What is code review like?
We have a very standard approach to code reviews. Internal tools alert assignees about code reviews through GitHub and Slack. Any Gusto engineer can search and view other pull requests (PRs). We have an automated build, which runs through Buildkite, and each PR must pass our entire suite of tests.

However, my favorite approach toward code reviews at Gusto is pair reviews, especially if the PR is particularly involved or complicated. When I am confident that my code meets requirements, I’ll schedule time with someone who I feel is most knowledgeable or has the most context on my PR.

These reviews happen in-person, at a pairing station. That way we can have very active discussions and short feedback loops, while clearing any misunderstandings on the spot.

I’ve found that this is extremely helpful when wanting to discuss my implementation and trade-offs of other ideas I had in mind. Also, as the reviewer, it gives me an opportunity to get more context from the original owner.

How is testing done, and what kind of tests are run?
We have an extensive suite of automated unit, integration, and end-to-end tests. Our continuous integration (CI) process runs all our tests with every commit, even on branches, using Buildkite. The main tools we use for writing tests are RSpec and Mocha for the back-end and front-end, respectively. We also leverage these additional frameworks and libraries to better support all of our testing needs:

Additionally, we enforce the use of linters, such as RuboCop, ESLint, Sass-lint, for code consistency across all of our repos.

How is code deployed?
We practice continuous delivery, so any PR that is merged, must be safe to deploy. A PR will first merge into our development branch that will automatically deploy to our staging environment. If the change looks good on staging, we will merge the PR to master, which is then deployed to production.

All engineers have access to Slack bots that can trigger a deploy. When triggered, it’ll find the latest commit on development that has passed our test suite and send messages to an AWS SQS queue. That then gets picked up by a Jenkins job and kicks off our deployment job.

All of our assets will build, compile, and get pushed onto S3 after the PR is merged. This speeds up our deploys because our assets are already available when we want to deploy a particular change. We also leverage Cloudfront to quickly and securely distribute them to our users.

We use Capistrano, a Ruby gem, to handle our rolling deploy, which will stop and start servers individually. It’ll fetch the latest code from GitHub and restart the server while ensuring customers can still access our app even in the middle of a deploy. The restart also runs scripts to configure the box as expected, which includes bundling all necessary gems and establishing required connections to the database.

Additionally, we’ve recently enabled our app to run migrations out-of-band with the help of gh-ost. It essentially streams data from the original table into a new table with an updated schema and swaps the tables when safe. This ensures our app will have zero downtime during all deploys (exciting updates about our migrations coming soon!)

Swag from our most recent hackathon.

What is an average day-in-the-life of someone on one of the development teams?
This varies for different teams, and even from person-to-person, but usually one can expect:

  • Daily stand up, either in person, through Slack, or over our SF-Denver portal
  • Pairing session
  • Personal time to code, merge, and deploy PRs, and do code reviews
  • Context-sharing and technical discussions in person and through Slack
  • Occasional lunch sessions such as brown bags, where team members will talk about slated projects or have technical deep-dives

What makes Gusto a special place to be a developer?
Everyone is extremely friendly! People are extremely willing to roll up their sleeves and jump into your code, even if it’s in unfamiliar territory. I’ve had people from completely different teams debug really hairy issues with me.

To tack onto that, I believe we’re constantly striving to be better. We call the dedicated weekly, on-call engineer, the “Viking Master” (VM). Because of the nature of on-call roles, it’s not as desirable as working on new features, but we take strides to improve the process. Whether it involves adopting completely different processes, pairing with another engineer, or even taking a couple silly pictures, we’re always trying to make unpleasant experiences at least a little bit more palatable.


A Viking Master on call

Can you tell us a bit about your team and what you are working on?
Engineering has six different missions—Payroll, Benefits, HR, Growth, FinTech, and Infrastructure. I’m on the Payroll mission, which itself is split up into three subdomains. They are called Running Payroll, Setup and Onboarding, and Payments and Filings.

I work in the Running Payroll subdomain and am part of the Run Payroll Upgrade Team. We are currently refactoring our run payroll flow from Backbone to React. Because it’s one of our older flows, most of our teammates who originally built it are no longer at Gusto. Although it raises a lot of questions about the behavior and intentions of some of the interactions, it really challenges and flexes muscles required to interpret legacy code and fix unexpected behaviors.

It’s rewarding to reduce our reliance on an older, less predictable framework and lay the groundwork so developers can build quickly and assuredly on top of our work.

About the Author
Jocelyn is a software engineer at Gusto and San Francisco native.