Comment by anthuswilliams
2 days ago
I have been championing this mindset since well before LLMs. It is an admittedly controversial opinion, but one I hold strongly.
Code reviews are a productivity tax. No truly effective team would rely on them. The fact that so many software teams view them as indispensable just shows how few effective software teams there are in our industry.
They are akin to a quality check step in manufacturing. Part of what Deming did in revolutionizing manufacturing was eliminating the step in favor of a holistic quality metric owned by all participants and enforced with rigorous statistical process controls. As you say, we in the software industry have all the pieces (autoformatters, tests, benchmarks, etc) to operate this way, but it seems our organizational and management dynamics combat this shift at every turn.
Relevant: When this conversation comes up at work, I like to share Avery Pennarun's post about the review tax: https://apenwarr.ca/log/20260316
> owned by all participants
How does this work in practice? In my experience, any metrics owned by a group inevitably languish and are largely ignored.
Anything you want to improve needs a DRI.
You still have a DRI. In factories this would be a foreman; in software teams this could be a team lead or product owner or whatever. Their job is to apply the statistical process controls and the gemba walk, to help the team see the problems and develop the causal mental model for why the problems happen. They hold the team responsible, together, for combatting the issues so uncovered. They know who is not pulling their weight.
Of course, to do that, a business, and in turn the DRI, would have to empower the team to act in its business's best interest and stop micromanaging them.