Written by Jake Smith, Platform Engineer II
Platform & Developer Productivity Creating Self-Service for Devs
At Omada Health, we like shipping software fast. It allows us to inspire and engage participants and work them more effectively for healthy lifestyle changes. In order to do that, we need to have a team that is well-integrated and responsive to the needs of our developers so that developers can do what they do best — develop! The platform team at Omada fills that need and is constantly looking out for how to streamline our processes and code to enable collaboration and understanding. …
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.
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.
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
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:
In the previous post, I went into detail about the value of sustainability. Today I talk about 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.
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.) …
Written by Lillie Chilen, Engineering Manager
One of the cornerstones of our engineering process at Omada is the retro (short for retrospective). A retro is a regularly scheduled time for the team to reflect on the past week and discuss what about our processes we should change to make the next week better. Most of our teams have retros at the same time each week, toward the end of the week.
Retros at Omada started with the engineering teams, and over the years we’ve introduced other parts of the organization to their magic. From the outside, retros can seem like post-mortems or complaining sessions. So it’s been important for us to emphasize that retros are regularly occurring and process-focused. …