Striving in the Time of COVID-19 — My Second Summer at Strava
Hi! I’m Kurt, I’m an Android engineer intern on Strava’s Trust and Safety team. After graduating from Gonzaga university last May I made the move out to Denver to join Strava’s Business team also as an Android Engineer Intern. Since then I’ve completed my first year of a computer science Master’s program at Eastern Washington University and have returned to Strava for yet another summer of running, cycling, striving, and Android development.
When COVID began closing gyms, cancelling plans, and urging people to practice social distancing, I saw a lot of my friends turn to running, cycling, and in turn Strava as a means for staying active and connected during such uncertain times. Despite getting the call that my internship was to be moved remote (which put a hold on my plans for tackling the remaining Colorado 14ers), I was very excited to return to work on a product that not only did I enjoy but that I was watching have a positive impact in those around me as well.
Working Remote
Right around when I was browsing apartment listings in Denver, I got the email that Strava was officially work-from-home and the entire intern experience was going to be pushed remote. While bummed I wouldn’t get to see everyone in person, I knew that experiencing the challenges of a remote working environment now would make me more adaptable and productive in the long run.
You can learn a lot about someone by their Zoom background. Whether it’s virtual or real, most people (though probably not willing to admit it) have put something behind their usual video conferencing spot that they would be happy to talk about. While the nuances of working remote were well dialed and the workday was smooth, the bikes, running race numbers, and mountain landscapes featured behind the grid of my coworkers on screen served as a bittersweet reminder that in less pandemic-y times, the Strava workday would often blend into early morning bike rides, lunchtime runs, and weekend hiking trips.
Android Engineering
Well now that you’ve indulged me in rambling about how I miss Colorado, we can get to what you’re actually here for: an exhaustive discussion about why introducing a Kotlin-Reflect dependency may not merit a 0.7MB APK increase. Just kidding. But let’s do get on to some of the technical contributions I made and the lessons I learned along the way.
Despite my 9 month hiatus from the Strava Android codebase, the first bug fix, the first feature implementation, the first commit and push were far less intimidating than they were at the same time last year.
Much like last year, shortly after my internship started the company shifted gears into “Guild WeekWeek,” a two week sprint where engineers pause the work on their usual product teams and instead meet with the other engineers on their same platform. These weeks allow each platform to catch up on tech debt, build new dev tools, make app-level upgrades, and work on other projects that are important but don’t fall under the jurisdiction of any particular product team. For me this meant building a network logger.
Network Logging and the Underrated Art of Dev Tools
When building features that interact with Strava’s API, ensuring the proper content and delivery of requests and responses that Strava sends can be a particularly tricky task. The network logger that I built serves to mitigate these challenges. Because it is a tool that is exclusively for our developers, a lot of considerations had to be made about the way it interacts with our non-developer users as well. In app development usability is the name of the game and with an app as feature-rich as Strava, even milliseconds of additional load time for users is not an acceptable sacrifice for a dev tool. The network logger needed to be as lightweight and streamlined as possible.
The network logger has three main components; the interceptor, local storage, and the display UI. Since the network logger is a superuser/debugging tool there is no need for it to change any data that it intercepts — thereby acting as a simple observer of network access. The interceptor receives any requests or responses going in and out of the Strava app and immediately makes a copy and pushes the data on to the OkHttpClient. For regular users, the interceptor is blocked even from this activity, observing nothing and immediately pushing the data forward. For our superusers, the data that has been copied is saved in a local Room database, ready to be presented should the user navigate to the tool’s UI. The local storage, when in use, is also streamlined to only cache a finite number of requests and responses to ensure a smooth experience for employees as well.
Trust and Safety
Upon the completion of Guild WeekWeek, I fully moved into my role on the Trust and Safety Team. On the Trust and Safety Team, we focus on all the aspects of Strava that make users comfortable with their data, our product, and sporting in general. This means managing reporting tools, privacy settings, user data control, and more.
One of the things that sets apart a good programmer and a great programmer is their ability to create extensible solutions. It is one thing to be able to build a feature, but it is another to build tools that can be reused for building many later features. While I felt very adept at building singular features, I wanted to hold my code to a higher standard and see it become something that can be reused at Strava long after I return to school.
The first feature that I built while actively pursuing these goals was adding a new option to our past activities editor settings. Up until now it was only possible to update the visibility of an activity, but with minimal work server-side, we wanted to add the ability to show or hide an athlete’s heart rate data on past activities as well. Migrating a workflow from one possible option to multiple is usually the most complex hiccup when building the extensibility of a solution. Adding the heart rate flow required some refactoring of the data structures that maintained the state of the UI and the data submitted.
Following the completion of the edit past activities project, the Trust Team as a whole was shifting gears to start a new feature of more detailed segment reporting. This new work would enable users to benefit from and contribute to the knowledge of the community — starting with specific, on-the-ground details about the conditions of a segment.
Last year the project that culminated my internship was closer to a solo effort. I had mentorship and plenty of people to turn to for guidance and it was very rewarding being able to own a project from start to finish, but this year I wanted to get more experience with the challenges that arise in parallel development. I decided that I would take the reins on some components of the front-end experience for segment reporting.
Besides making sure the UI matches the expected behavior for specific workflows, I also created one of the integral display elements for the community report. We had a need to display a list of items, which if you know Android development you’ll know this is going to utilize a RecyclerView, but in this particular case we wanted to make sure that the list that we are displaying can handle a varying number of items without dominating the screen space. With the page already scrollable it didn’t make sense to nest another scrollable window so we decided that we should have an expandable view that can show the full RecyclerView list if it’s small or a dropdown expandable preview of the list if it is larger. A dropdown recycler view is not something that I could find a library for online and while it would be a bigger project, I knew that it would be very helpful in the future to build an entirely new view object that could fit this use case and any like it that we may later encounter.
And thus the “DynamicallySizedRecyclerView” was born. Without getting too into the nitty gritty, the DynamicallySizedRecyclerView is a child of the ConstraintLayout and comes complete with an expand/contract caret, a linear gradient opacity for the collapsed list, and the animations and transitions to make a very clean and professional looking component. I specifically designed the new view object to be as developer-friendly and customizable as possible. One function call gives access to the internal RecyclerView and from there, the behavior is identical. Other individual settings can then be configured manually like whether or not to expand or collapse the list by default, the thresholds for how many items to hide or display, or the number of items to display when collapsed.
Non-Technical Growth
It is impossible to work at Strava without feeling at least a little inspired to get on your bike or lace up your running shoes. It’s one of the major things that drew me back for a second internship. Even though we couldn’t ride or run together in person I’ve been hitting the trails more than ever. I haven’t clocked this many miles on my running shoes since high school track and cross country. While I’m still comfortably behind the mile PR that I’m striving to get, I’m headed in the right direction thanks to Strava and it has been a pleasure working on a product designed to help others reach their own goals too.
