Hacker News new | ask | show | jobs
by menzoic 419 days ago
Most places I’ve worked including Uber and Airbnb allow teams to contribute code to other teams services. Quality is protected by requiring “blocking reviewers” on pull requests. Blocking reviewers requires one person from the services team to approve the pull request.

I think this is better than requiring teams to make all changes themselves which slows things down significantly considering each team has their own roadmap and priorities

2 comments

You'd think so, but often the blocking reviewer is an entire team, including people who just aren't careful at all or who don't understand the downstream consequences of their actions, and not just the one person who has strong vision and cares about the process, because the one person is also a bottleneck.

Requiring reviewers isn't sufficient. It needs to require a cohesive review strategy that adheres to a long term product vision for the software component in question. And my experience, though not at the two companies you mentioned, is that it doesn't happen and you instead get a lot of thoughtless "yup, looks like code" approvals.

I know a team like this. They delegate relatively junior members to take inbound design consultations from other teams. They string you along for months with a tentative alignment. Then finally the real decision-maker reviews your proposal, and he wants a total do-over. So you've got 6+ months with nothing to show. Just incredibly antisocial behavior that has caused hundreds of wasted engineer-months and gotten some very talented engineers I know very nearly fired.

Upholding a strong vision is fine. But if you want to be a blocker, you've also got to be quick. The alternative is a bureaucratic death spiral.

I concur. Everything you said. Looks like code, approved. I also had a short stint at one of the mentioned company. This is not real code ownership with accountability. Accountability theater.
I think what you're referring to is the same as strong code ownership. Each repository/directory has an owners file which specifies who can accept changes. If someone makes a change in my repo, I still own that change because I accepted merging it.
Only as long as you truly have the power to say no. Which in my experience is fairly rare.