Written by Scott Stebleton, Senior Engineering Manager

You never get a second chance to make a first impression. First impressions last in just about every human interaction, from friendships to dating to schools and politics. It’s equally true when bringing a newly-hired employee onto a team: a department’s onboarding process shapes a person’s trajectory in the organization, from how quickly they ramp up to how engaged they feel, and everything in between.

At Omada Health, one of our company’s guiding values is Grow Together. For a new hire, that growth requires initiative and guidance from their leadership team. …

Written by Will Hastings, Staff Engineer

Welcome back to the saga of Omada Engineering’s adventures with GraphQL. In previous posts, I discussed our processes for learning and adopting GraphQL and the benefits it brought us. This time, I’ll share two technical tips we discovered while adding GraphQL support to our Ruby on Rails API server using the graphql-ruby gem. First, I’ll cover the code organization structure we chose and the benefits it gives us in terms of discoverability and maintainability. Second, I’ll demonstrate the solution we implemented for adding GraphQL-specific details to our server request logs.

Code Organization

By default, graphql-ruby generates the directory app/graphql/types for you to place the Ruby classes that define the types for your GraphQL schema. It also gives you the app/graphql/mutations directory for the Ruby classes that define your GraphQL mutations. We realized that adding all types and mutations to these directories without any further organization would quickly become a maintenance burden. So we chose to organize type and mutation classes into Ruby modules (and the corresponding directories on the filesystem) based on the category of data the types apply to. …

Written by Will Hastings, Staff Engineer

In my last post on our adoption of GraphQL, I discussed the process our engineers took in evaluating and trialing GraphQL as a technology for improving how we develop APIs. Throughout that process, we confirmed that GraphQL solves or improves upon several of the shortcomings we identified with the way we traditionally developed APIs. In this post, I’ll enumerate those shortcomings and how starting to build several new APIs with GraphQL has led to numerous benefits.

Documenting our API

We’ve always faced the challenge of documenting the structures and data types of our API’s responses and expected request formats. Lack of good documentation places a challenge on our mobile developers, who sometimes would end up reading through our backend Ruby code trying to figure out just what type a particular data point would have in a response. We tried a few different solutions, such as handwriting API documentation in Google docs or code comments and describing our structure/types using a YAML-based format. …

Written by Scott Stebleton, Senior Engineering Manager

Previously on the blog…

This is the second in a series of blog posts exploring the values held by our Engineering department, and how we put them into practice. As a refresher, our Engineering department’s values, in no particular order, are:

• Sustainability
• Mindful Collaboration
• Data-Driven Approach
• Shipping Software
• Diversity & Inclusion
• Learning & Innovation

In the previous post, I went into detail about the value of sustainability. Today I talk about mindful collaboration.

Value: Mindful Collaboration

At first glance, mindful collaboration may seem like a squishy subject that has little to do with software development. But in reality, the opposite is true: we are humans working together to build something we care about. Collaboration is a key feature of a successful company. (Company, after all, literally means multiple people gathered together.) So when we talk about mindful collaboration, we’re talking about building a culture and environment that is optimized for humans working together. …

Written by Scott Stebleton, Senior Engineering Manager

At Omada Health, we have a set of values that guide everything we do as a company. This post, however, is not about our company values, but the values held by our Engineering department. These are the principles that drive the work we do as software developers, data scientists, and infrastructure architects. These values are the product of brainstorming by the management team, and given shape by input and healthy debate across the entire department. …

Written by Will Hastings, Staff Engineer

We build a lot of APIs at Omada. We build them to power the web, iOS, and Android apps our participants use to interact with their health coaches, take their lessons, track their data, and more. We build them to power the internal web app our health coaches use to understand what motivates our participants and help them make better decisions, as well as the internal UIs our support teams and operations managers use.

Traditionally, we’ve built APIs using a mostly RESTful architecture and the conventions native to the Ruby on Rails framework that powers our backends. More recently, engineers from a couple of teams started exploring alternatives. After enumerating and considering the shortcomings of our current way of doing things, we decided to explore if adopting GraphQL would help solve some of our challenges. We experimented with and evaluated GraphQL through incremental adoption, starting with a minor internal facing feature, and building up to it powering the next major feature for our participants. …

Written by Lillie Chilen, Engineering Manager

In a previous post, I explored how running an internship program can benefit the team (and the company) more dramatically than you might expect. Now that you’re totally bought into why interns are awesome, you’re probably wondering how you can run an effective internship program at your company.

How our internships work

Whether the internship is three, four, or six months long, an Omada engineering internship follows the same general format: join the team and pair with everyone, do a solo project for a spell, and then rejoin the team. We’ve had 13 engineering interns so far, and each came to Omada with a different amount of experience with our stack. Having them start with the team gives us a chance to share our practices with them, and dump a heap of knowledge on their heads while they learn their way around the codebase. The solo project then gives them a chance to integrate some of that knowledge, and code review helps us and them see what they are still struggling with. …

Written by Lillie Chilen, Engineering Manager

Hiring an intern is obviously beneficial to the intern: they get paid to learn to write better code, they get exposed to working with a team, and they get another line on their resume working toward being a “supes profesh” software engineer.

Less immediately obvious, though, is how great an intern can be for your team and your company. A good internship program provides an opportunity to look critically at your culture and your codebase to see where the weaknesses of both are.

(It’s unfortunately easy to run an internship program without learning from it, but if you set things up properly and ask the right questions, having an intern on your team will pay dividends beyond their comparatively cheap salary.) …