Fun. Challenging. Rewarding. This combination of words was not what I expected to experience while working full time at a tech company. I can honestly say that working at Strava has truly set the standard for how I want to be treated at a company, and also the type of stimulating problems that I want to tackle. This post will express my journey through not only the project that I worked on, but also the fun times that I had here as well.
I was surprised to learn there were only 10 people on Strava’s infrastructure team, and it was these 10 people that helped maintain an app that had millions of uploads a week. Finding out that I would be working on this team was even more shocking. I was nervous but I was also eager to find out the project that I would be working on. Two very amazing things have happened since I started working on this project: I discovered an entirely new side of engineering which has definitely piqued my interest, and I also discovered that I love coding! (I also ran a lot)
My project was about creating a feature gating service that will be used by the product engineering teams at Strava. As exciting as that sounds (super cool right?), the need for this service was actually very large. Our product teams are big proponents of running A/B tests, but the experimentation tools we have aren’t expressive enough to concisely cohort and filter by the many dimensions of our athletes. Moreover, we needed tooling that worked throughout our server stack, written in our two primary languages — ruby for our web tier and Scala for a mesh of backing services. The feature gating service would basically do a bunch of checks to see if that athlete will have access to a given feature or not. For instance, our growth team wants to experiment with a new checkout page, but only wants to release it to users in Spain. This tool would allow for that to easily be accomplished. My first task was to create functional parity between the current Ruby implementation of our feature gating service and the Scala implementation, which did not exist yet. This was the beginning of the incredible learning curve that I had to figure out because I did not know Scala and I also did not know how Strava’s internal services communicated with each other.
It took me awhile, but I overcame a lot of the obstacles that presented themselves during my journey to learning Scala. I ran countless Google searches and reviewed even more stack overflow issues in an effort to research how scala services are written and then utilizing this within the context of Strava’s code base. Conquering this learning curve involved learning about case classes, implicit objects, companion objects, utilizing open source APIs, and much more. I discovered a lot about the way I most efficiently learn new topics during this process and am very grateful because now I can apply this new knowledge towards my future endeavors in learning new concepts.
After I created parity within the two implementations, it was now my turn to introduce my own code and start implementing some additional feature checks that were not there before. The first thing to do was to write some optional filters that would allow feature developers more fine grained control over which members would have access to a feature. These included client mobile OS version, app version, locale, and build type. For example, filtering to a given locale allows us to easily roll features out to a smaller targeted population for evaluation without going through our full localization and translation process up front. This was an additional learning opportunity because Scala is such an elegant beast that can do some really fancy tricks. Don’t forget that since the service still needed to maintain parity between both implementations, all the additions I made in Scala also had to be on the Ruby side of things.
Accomplishing the creation of these additional filtering options was immensely gratifying, which led to the next challenge: creating a user interface (UI) on the feature admin pages. This UI would allow for engineers to conduct A/B testing much easier since it would mitigate many of the boilerplate configurations. The only difficult part about this is that I had not done full stack web development before. I spent many meetings with web engineers in order to get the rundown on how Strava does web development and how to utilize their best practices, which was actually really nice because I was able to meet a bunch of new people on other teams.
During this time, I also received many affirmations on how important this internal tool would be to the organization. Receiving this feedback really helped motivate me to work on meaningful projects and to ensure that I am making an impact. Strava was definitely the place where I discovered my worth and how I would want to be treated at a company. This leads into the super exciting fun parts of the summer :)
Not only did I advance my technical skills by completing my engineering project, but I got to experience Strava’s unique company culture. Imagine being able to go on weekly runs with your engineering manager, director of engineering, and also your CEO! Seeing such a passionate group of people who practice what they preach and work even harder at making the app they love better is an amazing sight. It truly shows you what “love the work you do” means. I’m so grateful to have been able to experience this at such an impressionable part of my work career.
Through this amazing culture, I was able to accomplish many of my side objectives for the summer. One of the goals for myself was to be more active which definitely made Strava an amazing fit. I even set a personal goal for myself to run from Fisherman’s wharf to Golden Gate Bridge and back (a total of 9 miles!!!). During the weekly runs I could feel myself becoming more comfortable with running long distances and before I knew it, I was running 5 miles on average per workout! This was insane because the most I ran before the summer was about a mile or two at best. Long story short, by the end of the summer I had accomplished my monstrous goal of running from the wharf to the Golden Gate Bridge. Strava definitely helped motivate and encourage me to accomplish goals that may seem intimidating at first, but are extremely rewarding in the end.
I was also a part of the Engineering diversity and inclusion group which was really cool because I had the opportunity to have actual insight and a voice into how the organization handles diversity and increases the opportunities for engineers applying to Strava. One of the avenues that I had an impact on was the advocation of new job posting boards that focus on underrepresented groups as well as suggesting mentorship opportunities for interns outside of Strava. It is extremely valuable for an organization to be involved outside of its own bubble; not only for the exposure, but for the diverse opinions and views that are able to be seen and felt through interacting with another human being.
All in all, Strava was an amazing experience and I couldn’t have asked for a better introduction into the tech world.