How to get commits merged in faster when changing other teams' codebases?
My work will often times span across multiple services within Uber, which means that I need to write code in codebases outside of my team's. Sometimes when I do this, it takes a long time for my commit to land as there's many rounds of follow-up questions, leading to a lot of rebases, revisions, and time spent on my end. I understand that they're trying to be the best stewards of their codebase, but this can be a bit frustrating sometimes. How can I make this process smoother and land these kinds of changes more quickly?
![Uber is an American mobility as a service provider, allowing users to book a car and driver to transport them in a way similar to a taxi. It is based in San Francisco with operations in approximately 72 countries and 10,500 cities in 2021. Its services include ride-hailing, food delivery (Uber Eats and Postmates), package delivery, couriers, freight transportation,[2] electric bicycle and motorized scooter rental.](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Fuber_logo.jpeg%3Falt%3Dmedia%26token%3D05497633-e202-42a4-9d72-02a87177ed26&w=3840&q=75){kind=logo}
Discussion
(1 comment)- 2
2 years agoStaff SWE at Google, ex-Meta, ex-AmazonHow much you can do yourself may be limited, but have some thoughts.
Get a buddy assigned from the owning team, and clear everything with them in advance. If they want a more senior engineer on your side reviewing BEFORE you reach out to their POC, fine, do that. There should never be a surprised CR dropped in their lap. They should know about the design, the phases, the timing, how invasive the code is, etc. Once you have a buddy, it will be much easier to iterate and land your change.
However, embedded in your question is an assertion that often you have to do this. Why?! If there are not clear boundaries, ownership, plug-in models, async notifications to trigger cross-service behaviors, and other mechanisms to avoid this, there should be. At most you should be adding a socket that is pushing a message out, or pulling a call in. If there are concerns that this is too slow, this probably means that you’re adding something to the critical path and not asynchronously. This should be the vast minority of the time, and even then, the invasive part of the code should be calling to a module your team owns, with strict timing thresholds to avoid performance regressions. If you have conditional statements in the other team’s code, stop and find a different solution. Especially if this is happening all the time, decoupling is going to make everyone’s life much better.
The other advice is more for leadership. You are not being a good steward for your team if you are sending them on away missions all the time. You should be getting your work on the other team’s roadmap in time, or funding headcount for them to give you N weeks per quarter to do this work, or horse trading to take on work they need, or factor old debt your team introduced out, or whatever so THEY do the work in their code base if that’s truly where it belongs. If your team is taking on some more mundane tasks for them to free up their on-call to do your work, do that. Whatever keeps you from having to mess with their code, do it.
The biggest problem with you changing their code is on-going support. Are you getting paged when your code breaks their service? Or there’s a suspicion thereof? Will you support it for a month after you ship it then hand it off to them? It yields poor ownership and decreases their understanding of their own service.
