Editor’s Note: This is the first post in a series of interviews with our team of engineers at Rover. We’ll introduce you to one of our Rover engineers, share their daily work and give you a sense of what it’s like to work for Rover. If you’re interested in an engineering career at Rover, check out the current Engineering positions.
Rachel’s role as tech lead for developer tooling on the Rover engineering team includes long-term planning, prioritization, code reviews, and working with teams on new tools. With Rover’s explosive growth, her new role was developed in late 2017 to devote more energy to dev tooling for quality assurance and productivity.
What do you do as a Rover engineer?
Tobin: Dev tooling covers anything a developer needs to get their job done and make their lives easier. This can be anything from updating code on the website, ensuring the code that is shipped is of a certain quality, and looking at what kind of automation we can introduce to make sure things like “oops, I forgot a semi-colon here” doesn’t get out into production.
What’s your favorite thing about working at Rover?
Tobin: I love the energy! We’re achieving cool things and everyone is growing so the environment is very motivating. Being able to affect decisions and be a part of that is exciting. What we’re doing now is so different than when I started two years ago because of the increased scale and volume.
The culture here is to move fast. Why wait? We can get the code out and start collecting data on it right now instead of waiting a week and get hamstrung.
What’s it really like working with dogs in the office?
Tobin: The dogs in the office make it cool. I grew up with dogs. I’m now more of a cat person, since I’m at a point in my life where I prefer lower maintenance pets. If I was to get a dog, I’d want a herding breed who have a huge amount of energy. In the meantime, I can come into the office and pet all the coworker dogs.
Tell me about your your typical day at Rover.
Rachel: Coffee. First thing in the morning, coffee. While I’m commuting, I’m catching up on Slack to see what happened overnight. Our infrastructure team gets here very early, so then my next priority is to check in with them. Then my team has a daily stand-up at 9:45am. There’s about seven of us who cover dev productivity and performance and our team name is the “Ibizans,” which is an uncommon breed of a hound dog. In fact, each of the nearly 10 engineering teams here has an uncommon dog name like Jindos, Ridgebacks, and Salukis.
After stand-up, I will start looking at code reviews on GitHub, which is a decent chunk of what I do. Other people have submitted code changes and I review them to make sure it’s accomplishing what we want it to accomplish and the style is accurate. That will lead to conversations to clarify could we do this in a different way, what did you mean here, etc.
Who is typically submitting changes to code?
Tobin: Anyone at any level on the engineering team can suggest a change to code. The process is democratized. And there are no strict rules on who can review code. You want to find someone with the most knowledge and context because we view code reviews as a knowledge share as well. The review process can be really useful for less senior engineers to see what thought process is involved so they can understand the code better in the future.
What’s the processing of updating code?
Tobin: We also deploy code 20 or more times a day. A lot of times companies will do staged releases and they’ll build up a version and ship it once a week or once a day. For me to get code out in the wild, I make a PR, someone reviews it and it can immediately ship. You can push a button and it will go through automated processes and then it’s out in the wild.
We trust our developers to be able to push that button to deploy. We’ve also had a pretty heavy reliance on automated systems. Our testing suite is very large and robust. The culture here is to move fast. Why wait? We can get the code out and start collecting data on it right now instead of waiting a week and get hamstrung.
Tell me about a recent project and how it’s impacted your day-to-day?
Tobin: We recently made a big switch with how we deploy our code. We switched from a long-time tool in the tech industry to a different service, Buildkite, that will run our tests and eventually deploy the code. It’s been a game changer for us. We pride ourselves on our deploy times—we can get something out in 20 minutes. With the previous tool we could only get something out in an hour. With this new tool, we’re able to see much faster build times, and ship things faster to benefit the customer more quickly.
What do you do for fun at Rover?
Tobin: I’m part of a video game and board gaming group here. We have a Switch in our “Poodle” conference room and we have a board game library. We play a lot of Dominion since it is easy to pick up and play it relatively quickly.