Why Code Authors Should Have the Final Say on Code Reviews
Philosophically, I hold the (sometimes controversial) view that no developer—or any worker, for that matter—should be forced or coerced. This fundamental autonomy is essential for individuals to feel like true professionals—and, more importantly, like human beings. So, when safety or legality isn’t at stake, I believe it’s best to advise and then leave the final decision to those doing the work—code reviews included.
Beyond the philosophical rationale1, there are practical reasons for giving code authors the final say in code reviews.
Since code changes are reversible, much of the fear surrounding potential errors is unwarranted. Code errors are released inadvertently every day, and companies fix them and move on. What matters most is having infrastructure that supports quick, seamless rollbacks and releases. With these safeguards in place, developers can experiment, learn, and even fail safely. Allowing them to make decisions about their work provides the most valuable experience: production experience. Successes in production are remembered with the greatest pride, and mistakes made in production are far less likely to be repeated.
Let’s also remember that reviewers aren’t always right—even when the majority opinion disagrees with the code author. After weeks (sometimes longer) spent tackling a problem, the code author is usually the most qualified in that specific problem’s domain, unlike team members or leads who’ve only engaged with it for the hour or so it takes to review the code. More often than not, it’s better to trust the code author’s judgment.
In fact, I’d argue that the code author, by virtue of their time and effort, deserves the chance to see their proposals in action. They’ve earned the opportunity to prove their detractors wrong. And if they do, the entire team gains a valuable insight. This is the essence of innovative discovery: challenging and dismantling false intuitions2. Such insights expand everyone’s thinking—an opportunity lost if the code author must always defer to reviewers.
Lastly, there’s a practical concern that often goes overlooked: not all code needs to be polished, fully tested, and production-ready. Exploratory work, like prototyping, doesn’t require the same rigorous quality control as production code—it certainly doesn’t need perfect formatting. A prototype is a tool for gathering information without over-committing to one implementation, much like an artist’s rough sketch. It’s clear enough to convey an idea but messy enough to be recognized as unfinished. Unfortunately, many code review processes slow down rapid prototyping by insisting that prototypes meet a strict “definition of done.” Agile is about “the art of maximizing the amount of work not done.”3 Polishing code that’s in a tentative, exploratory phase (a phase more common than many realize) is wasteful. Giving developers the final say in reviews lets them decide on the appropriate level of polish for their context, freeing them of unnecessary demands for refinement.
This isn’t to say developers should disregard others’ opinions. Advice should be taken seriously before making decisions. Repeatedly ignoring sound advice, especially if it leads to poor results, should prompt serious conversations. But addressing repeated missteps after the fact is very different from preemptively controlling each step, as is often the case with most code reviews.
Conclusion
Developers are often urged to take more ownership of their work—so why not grant them real authority? After all, ownership is meaningless without the power to make decisions4. Allowing code authors the final say in code reviews provides them with the autonomy they need to learn, succeed, and feel valued as professionals.
I plan to expand on this philosophical stance in future essays, but for a quick preview, it pretty closely aligns with the insights Doug Kirkpatrick shares in his TED talk.
Think of Galileo insisting that the Earth revolves around the Sun, or Einstein proclaiming that time is relative.
https://agilemanifesto.org/principles.html
Imagine “owning” a toothbrush that you can’t stop others from using to clean the toilet—because you lack any real authority. That’s ownership in name only, and it’s hardly worth having.
> After weeks (sometimes longer) spent tackling a problem
If you are submitting a single PR after weeks of work, it sounds like the real problem is work has gone on too long without feedback. Current industry practice says you should be committing to mainline daily. In other words, you should have your code reviewed at least once per day.
This feedback cycle of weeks before discussion explains why you might be passionate about this.
However, the real answer to "who should have final say" is whoever is going to:
1. Wake up in the middle of the night if it's an issue
2. Work on future iterations of the code the most
I think this becomes the most clear in open source land. Say you spent weeks adding a feature to an open source project in which you aren't a maintainer. The maintainer has feedback. Who's gets final say? The maintainer, not the PR author. I think it could be helpful to ask why the PR maintainer gets final say. It's not just because of social contract.
After reading the article I did notice that I tend to give the devs the responsibility (authority to make final decisions as well as carry the consequences of such) wherever possible. This actually also includes asking them first whether they want to take part in the project or do a special task in the first place. It's too soon to tell how much better this approach is than simple "you do this, you do that". My thinking is, that you can not embrace any kind of responsibility, if that responsibility is enforced on you. You can not care, if you are a prisoner. I can argue why I think "doing this, doing that" may be good for you/project/team, but enforcing stuff makes things easy in the short run and hard in the long run.