Finding Impactful Engineering — A Case Study of my Summer at Strava
Introduction: My Strava Story
Hey there! I’m Daniel, a web engineer intern on Strava’s growth team. I’m an incoming senior Computer Science major at UC Berkeley and a Bay Area native. My own Strava story started a few summers ago back in high school. It was back in 10th grade when I bought my first road bike with no background in endurance sports, and first started using Strava to track my rides.
I think many of us have a Strava segment that we care about more than we’d like to admit to. For me, it was one of our local Peninsula Bay Area hill climbs, King’s Mountain. In the summer of 11th grade, I rode the hell out of this hillclimb. I remember comparing all my segment times up the climb after each ride, looking through my pacing and power profile for the segment each time. I loved shaving time off my segment PR’s and I used Strava as an extension of my ambitions to drop time on my segments.
Preface
At the beginning of the summer, I told my manager, Will, that one of the long-term goals I had for the summer was to make sure that I’m not a close-minded engineer. As an undergrad student, I still have an entire professional career ahead of me in my life, and I want to enter my career going in with the right perspective and the right mindset so that I won’t hinder myself by having the wrong approach. I felt that it was important to both understand and be conscious about how the rest of a company works, the different job roles, and how software engineers fit into the picture. In turn, understanding this would let me perform my job as a developer more effectively to the benefit of my team, the product and our company.
At my internship, I was designated to be a front end web intern, but in this post I’ll explain how my internship extended much further than our front end web stack. I’ll be reviewing some of the most important things I’ve learned and worked on this summer in the rest of this post. The technical portion of this post won’t focus on implementation details or go into depth about the technical architecture and design of Strava’s tech stack, but aims to shine some light on the bigger picture that my work contributed to and to focus on the ‘why’ and impact of my work. I’ll then review some of the meetings that Will set up for me after the conversation I had with him that I described earlier. These meetings focused on discussions I had with non-engineers at Strava and why I’ve come to see the importance of how the bigger picture matters even for engineers.
Technical
Frontend web development
Much of my front end work this summer involved digging a few levels deeper than just the frontend portion of the codebase. Oftentimes, I’ll need to hook up parts of a new web page or feature to Rails models, controller methods, and more. Working through other parts of the web stack, beyond just writing templates and index.js files all the time, helped me better understand Strava’s web architecture, study the design patterns within our codebase and learn how different pieces of code interact with each other to serve the pages on our site.
At Strava Jams, our internal hackathon event at Strava, my project first started as a way to embed a route in an iframe, so that we can use it in our Strava Blogs, and in 3rd party sites like race signup sites, personal blogs and articles. One of the issues I had with this was that I’d be creating a new endpoint, but it would be using an older version of our Mapbox map and elevation chart. I felt that it wouldn’t be right to create something new just so that it would use old technology. Instead, I thought, it would be more useful to our team if I refactored the page as a React app, before importing specific components to create an endpoint for embedding. This refactoring was more in line with the direction that our front end teams are moving towards, and lays the foundation for future use of these shared React components for different pages and apps. What I ended up with after my Jams project was a React app that includes updated components that can be imported into an embed endpoint. This app provides the groundwork for future React development, which would provide value for our team even if my entire hackathon project wasn’t shipped to production.
SEO
Search Engine Optimization is a subtle art. The concept of it is simple, but in practice, involves a lot of fine tuning and is hard to nail down for this reason. The usefulness of implementing foundational SEO features for your site is that it provides huge gains in visibility and traffic to your site for a relatively small amount of work. One of our current goals is to expand the SEO features included in Strava Local, a site within Strava where people can find curated running and cycling routes in popular areas with interactive maps. Strava Local is a good target for SEO because it covers an important area of search traffic, and between all the different countries, cities, and routes, has many areas of opportunities for adding SEO features.
When I was developing a new view for Strava Local, one of my conscious efforts was to keep in mind that I was including the right SEO strategies, and to create my webpage with purpose. Adding keywords, internal linking, alternative tags, and relevant content to the page so that you improve the quality of your page content for crawlers to see is key. One of the more important SEO features to add are breadcrumbs. For example, if we were presenting a page about cycling routes in London, the breadcrumb preview on a Google search result with our link would look like “United Kingdom > London > Cycling” to help give both Google and web users context for web pages. Breadcrumbs are an important feature because it provides extra contextualization on your web page in a page full of search results that helps your site stand out and becoming more engaging to the user, and to help users know that they’re clicking on the right content.
A website filled with awesome image and video content will go unnoticed in the eyes of Google. No matter how good of a website you built, it’s hard to optimize your site to rank high on search results if you don’t consciously keep it in mind during your development efforts. SEO is critical to gaining exposure for your site, and is one of the most important ways a developer can promote their site online. Thanks to the SEO features that I’ve implemented in Strava Local, we increased traffic to Strava Local by 20%, and increased the overall CTR to Strava from Google search results by 1%.
Parallelization in Cypress Testing
Our front end QA test suite is handled in Cypress, and it’s a critical point of our web workflow. This test suite, however, is prone to flakes, where tests that should pass will fail. When a test flakes, we have to rerun that worker’s test suite, which could turn a 10-minute testing process into a 20 or even 30 minute testing process. This creates a large bottleneck for engineers since all deploys in our web development need to run through this suite before changes can be deployed to production.
One of my Guild Week projects was to identify problem points within our test suite and to speed up the testing process. We began by recording tests within our suite that would cause frequent flakes, so that we can prioritize the most unreliable tests to fix first. To greatly improve the speed of the test suite, I tripled the number of workers running the test suite. Because parallelism is limited by the law of diminishing returns, we want to find a balance between achieving good speedup while being reasonable in resource use. After my changes, the test suite runs in around half the time that it used to, five minutes instead of over ten minutes previously. This fix provides important value to our web team since it significantly improves on a portion of our daily engineering workflow.
Non-technical
Like I touched on earlier, my manager set up various meetings for me with product managers and managers throughout my internship. These meetings gave me context for how software engineers fit into the structure of a company, both at Strava specifically and at any company, from the perspective of managers. In the following section, I’ll be reviewing some of the questions I had and some of the other things I learned about during my conversations.
What’s one of the crucial jobs that PM’s do, and why do they do this; what does it provide to the team?
After talking to our resident product managers on the Growth team, what I’ve learned is that much of a PM’s job in their day-to-day is interfacing with other teams so the rest of their team doesn’t have to. They help progress the current team goals by facilitating the rest of their team. They have so many meetings so that they can do all the interfacing for the rest of your team, so you don’t have to be at those meetings. They save time for their engineers, designers, and the rest of the team so they can work on the actual implementation and nitty gritty details. Of course, their jobs are much more involved than just going to meetings, but this itself is a huge help for the rest of the PM’s team.
Do engineers need to be conscious of product direction, vision, and reasoning behind building features?
Coming into the meeting that I had with Jason, one of the engineering managers in Growth, I truly thought that engineers didn’t have to be aware of this. My thinking is that if both product managers and managers are fulfilling their role completely, that an engineer will always receive the right work to work on with respect to the team’s goals and the current product project roadmap. As long as these developers complete the tasks delegated to them, that they can be just as good as an engineer who puts thought about the kinds of tasks that they work on before working on. The answer I got from Jason, however, was a completely different one. He told me that engineers absolutely need to think about the product in their daily engineering work.
For example, my mentor as responsible for much of the front end for the website. As such, he has lots of areas of ownership throughout the site, and people are always approaching him with ideas, bug fixes, and features to implement or build on. His job is to consider the importance of all these tasks presented to him, the work he already has delegated to him from sprints and more. Whether he explicitly expresses it or not, he, as an engineer, is constantly thinking about the vision of the product, our current goals, and the impact of this proposed work.
Developers are almost always faced with a backlog of features and requests presented to them, and I was no exception to this this summer. It’s up to me to decide what’s most important to work on, and we as engineers need to use a product-minded mentality when prioritizing the work that we’re given. Constantly context switching whenever we’re given a new task is both confusing and ineffective for producing meaningful work.
I certainly won’t be a senior engineering manager anytime soon, but talking to your managers about managing your team from both their perspective and your own perspective is important. It’s important to both understand the perspective of the managers that you work with and to know where you fit in the picture of the team and product. Team members should be on the same page as their leaders, as it allows a team to align and work as one cohesive entity, without any one member straying from the direction that the team is moving towards.
Conclusion
When software developers label themselves as code monkeys, they’re both selling themselves short and implying a lack of responsibility and leadership in driving a team and product towards their goal, when engineers have a foundational role in progressing towards a team’s goals. What I’ve learned over the summer is that this doesn’t mean I constantly add features wherever features can be added. We need to make sure that the result of our work is impactful. We should have concrete reasoning backing up why we are adding this feature, and what it will do for us. In addition to adding features to existing pages, I added new web pages that includes relevant and quality content. This helps with the search rankings of our site, which I’ll expand on later. Being an effective developer means working on tasks that provide value and impact, and being conscious of how much value each of your tasks provide, the difficulty of each task, and the urgency of the task. Balancing all the work that’s been given to you, and prioritizing your work given to you will make you the most effective engineer you can be, regardless of whether you’re an experienced or novice developer.
I also could have made it through my whole internship without sitting down with any of our PMs or managers. At the same time, I think my time at Strava would have been so much less meaningful if I hadn’t taken this opportunity to take advice and learn from the rest of our team. An engineering internship should be a lot more than just about building out features. Working at a company is a huge opportunity for an undergrad student to get a glimpse of how companies made of many moving pieces of employees operate. With all the help I got from my manager with setting up meetings and checking in on what I’ve learned from talking to different engineers and managers, I was able to leverage this opportunity to be more thoughtful about my work and its impact in my day-to-day development. These types of lessons can’t be found in a lecture hall at university, or in a course textbook, but rather need to be experienced or realized through conversation and spending time working at a company. Working on this type of professional maturity is something that I’ve been eager to do, and I’m grateful that my interest in this idea was so welcomed by my manager and everyone I talked to at Strava who set aside time in their day to meet with me. When an engineer understands their purpose at a company, they become more effective developers, find both personal and professional growth more quickly, and ultimately become more valuable assets to their company.
