What would an Uber Engineering Manager do? Part 2

This is the second blog in a two-part series titled, What Would an Uber Engineering Manager Do? You can click here to read part 1. 

‍In May 2021, Gergely Orosz, author and former Uber Engineering Manager, joined by his colleague Abhijith Krishnappa, Software Engineer at Halodoc, led a Q&A session hosted by Bugsnag to share their perspectives on questions posed by the developer community. After a lively discussion, we were left with several remaining Q&A submissions. Today, we are happy to share written responses to those questions with you all.‍

‍
Q: Apps like Uber need on-field testing for tracking locations. How did you manage this type of testing?

A: [Gergely] We simulated location, for the most part, and built easy ways to do so in the app (you can also do it with the simulators). There’s little reason to test location yourself, as this approach works reliably. Additionally, we had contractors and employees test the app in the real world, as part of the beta program.

Q: I work on a small development team and our platform is constantly evolving. Do you have any recommendations on how to continue with automated testing when the code base is constantly changing?

A: [Gergely] You want to invest testing in-line with where your app is. When prototyping or doing MVPs – where the codebase changes massively – it’s not a great ROI to add tests early on. If you have an app that is more “stable”, the codebase should not be changing as rapidly. If it is, you might continuously be over-engineering. You want to slow down the pace of change/rewrites in my view: the fact that tests keep changing all the time can be a symptom of something else.

A: [Abhijith] Identify the volatile components. UI layers usually would be volatile as there will be experiments from product, UX research etc we need to accommodate. These can be excluded to begin with.

Q: What is Uber’s automated test case code coverage %?

A: [Gergely] I recall unit tests were about 70-80% of non-UI code (so interactors and other business logic). All business logic code would be covered by unit tests. Screenshot and UI tests were on top of this. Instead of measuring code coverage, I’d focus on making sure you test anything that can be a regression, and ask the question of “would an automated test have prevented this” on postmortems.

Q: How do you propose a new change in process and align the team with it? For example, say, if I want to enforce some guidelines for code reviews.

A: [Gergely] Find a balance between top-down decision making, and bottoms-up “everyone agrees with this already”. I would suggest bias towards the latter. As engineers, if we’re told to do something, we probably won’t do so, unless we believe in it. Convince people around you, get your team onboard, start doing it, then move upwards. This can be different if you are on a platform team who explicitly owns areas like this. Still, you want to start by listening, consulting and making sure all engineers are heard.

A: [Abhijith] Also, we can have explicit gates via tooling. Eg: Rules like Unit tests coverage of X%, Sonarqube errors to be 0, etc can be configured in the CI/CD pipeline itself.‍

Q: When a team has grown large enough to feature flag everything, how should the rollout of those flags be managed? Can individual feature teams still handle it on their own, or do you need a central team that is flipping all the switches?

A: [Gergely] Individual teams should definitely handle this! A central team is a recipe for disaster as they have no clue about the features. At Uber, teams always owned their flags. I cannot see another way.‍

Q: For “Feature Flags/Toggles”, are there any best practices you would recommend to make them more manageable and avoid being overused? Especially when their number becomes too much?

A: [Gergely] I cover this in the Feature Flag hell chapter in Mobile Apps at Scale. Basically, you need to come up with ways to retire rolled out flags. At Uber, we built and open sourced Piranha to do this.‍

Q: What are your thoughts on full stack development for mobile engineers (mobile + backend engineering)?

A: [Gergely] If your stack supports this: sure! At Uber, the setup and context switching was usually too much. Mobile engineers did make tweaks on endpoints every now and then, and backend engineers ran the app in the simulator, testing endpoint changes.‍

A: [Abhijith] It’s nice to get perspectives. At times, there are companies which follow Backend for Frontend (BFF) where in App/web developers define the API contracts as deemed necessary. However nowadays these are more often replaced by GraphQL APIs.

‍Q: Any experience/challenges with white-labeling apps?

A:[Gergely] No, none of the companies I worked at did this.