My Summer on Platform at Strava
My name is Vidya, and I just graduated from UC San Diego, where I studied Mathematics and Computer Science. This summer, I had the opportunity to intern at Strava on the Platform team, and learned a lot along the way.
Airbrake for Scala Services
My first project focused on integrating Strava’s Scala microservices with third-party software called Airbrake, which allows for easier error discovery through logging, visualizations of error specifics, and deployment information. Strava’s website and APIs are powered by Active, a Ruby on Rails application which contains the majority of Strava’s business logic. However, Strava has moved from a monolithic app (mostly contained on the Rails app) to a service-based infrastructure. Before this project, Strava engineers had been accustomed to using Airbrake with Active, but not with Scala services (which is where they increasingly have to work) — my project allows them to use Airbrake, and improve their error-discovery process, when working with services.
This project involved implementing three main parts:
- A Finagle filter that catches and sends notifications for fatal errors and uncaught exceptions to Airbrake
- Airbrake deploy notifications for service deploys (this was added to our internal deployment tools)
- A user-customizable severity filter to filter errors and set severity based on exception class name
This project reinforced several important lessons:
- Code should be extensible — thanks to a suggestion by another engineer on my team, I made the Airbrake filter generic so that it can be used with other failure filters. If we decide to use the filter with other software in the future, this small change will make a big difference.
- Simple is better. During initial design discussions, we thought that building the severity filter would require a prefix tree; we found that we could instead use a simple key-value Map, which worked exactly as intended.
- Documentation is important! I tried to ensure that the tools I worked on were documented in a detailed, thorough manner — this wasn’t the most glamorous part of the project, but I’m glad that clear documentation will make it easier for other engineers at Strava to use and benefit from my work!
I was excited about the impact of my project — from seeing a service error appear on Airbrake for the first time, to receiving enthusiastic Slack messages from other engineers who started using it for their work. This was an awesome first project, but it was only the beginning!
Jams!
One of the many reasons why Strava is such a special place to work is Jams — a 4-day hackathon during which employees are encouraged to pitch, build, and demo creative side projects that could potentially help improve the product or the company in some way.
My Jams idea involved using QR codes to share four features of the mobile app: athlete profiles (to facilitate following), specific activities, challenges, and clubs. This would make it easier for athletes to connect with one another and find content on Strava.
I worked with an Android engineer and a web engineer on the Summit team over the course of three days to bring the idea to life. One of the coolest parts of this project was the fact that I was able to work with technologies I hadn’t used before — my teammates patiently gave me crash courses on Ruby, Kotlin, and Swift. A happy side effect of the project: my computer’s Dock looked much more colorful thanks to all the new IDEs I had to download!
My main takeaway from Jams was that trying new things is extremely important — from pitching my project idea in front of the whole company to working on aspects of the product that I had been unfamiliar with. This project also helped me learn more about what engineers on other teams at Strava are working on, and how they work. It was especially helpful to gain perspective on how engineers outside of Platform work because the next project that I began working on after Jams is meant to help engineers across the company with their workflows.
Candidate Deploys for Scala Services
My next project was part of a larger collaboration between the Platform and Productivity Engineering teams which is focused on developer experience and productivity. The goal was to make it so engineers developing Scala services could test new features against real data without impacting athlete experience. This involved lots of planning — the team spent around two weeks drafting documents that detailed use-cases, goals, implementation plans, and potential pitfalls of the project. To determine a baseline for measuring its success, we drafted a survey which we sent to engineers developing new services. The next steps, which comprised most of the rest of my internship, involved working on deployment configurations for these new services. This was meant to allow different deployments of the same service to be routed to, with a focus on normalizing service naming and making things backwards compatible (so engineers can work with the new configurations without breaking existing things).
Working on this project reminded me that understanding your customers is important. Before this summer, my idea of “customers” had constituted end-users, such as the athletes who use the Strava app and website — I hadn’t considered internal users, like other Strava engineers. However, in writing docs that would be easily understandable for the Airbrake project, and in using surveys to collect metrics to understand how people might benefit from service canaries, I realized the importance of having a customer in mind.
Fun Non-technical Things
This summer, I learned how to make mochi with other #womenintech at Strava, went kayaking for the first time at a team off-site, befriended several dogs at the company picnic and on company-wide Dog Fridays, contributed two new coffee-related Slackmojis (:philz: and :philz-no-mint:), and discovered that many of my coworkers like Taylor Swift as much as I do. Most importantly, I went on so many one-on-ones that I think I may have set a company record, and met several incredibly smart, interesting people at Strava as a result. I made an effort to eat lunch, get coffee, and just chat with not only the engineers on my team, but also analysts, engineers, and product managers across the different teams at Strava. My advice to new interns is to definitely try to meet as many people across the company as possible — you will learn about the building blocks of the organization, the range of potential opportunities in the industry, and how to grow as an individual and professional from people who were once in your shoes.
Special thanks to Matt, Connor, and Sara (my mentors), to Julie and Aidan (my Jams team), to everyone I had one-on-ones with (Adam, Annie G., Brian T., Cathy, Chris G., David, Dickson, Elyse, J, Jeff, Kevin, Lulu, Melissa, Merty, Mindy, Nathan, Raf, Varun, Will S., and Yudi) and to the countless other people who helped me throughout my internship!
