.png)
4 months ago
2
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 rationale, 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 intuitions. 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.” 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.
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 decisions. Allowing code authors the final say in code reviews provides them with the autonomy they need to learn, succeed, and feel valued as professionals.
