Why Code Authors Should Have the Final Say on Code Reviews

1. The author quotes some VC&#x2F;excecutive consultant&#x2F;TEDx talk as the basis for the &quot;philosophy&quot;<p>2. &quot;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.&quot; No, errors get into production and stay there forever while customers get annoyed. Quick, seamless rollbacks and releases? Not enough.<p>3. &quot;After weeks (sometimes longer) spent tackling a problem, the code author is usually the most qualified in that specific problem’s domain&quot;. Cranks spend years coming with the &quot;proofs&quot; or theories like squaring the circle with a compass and straightedge and the experts dismiss them with 5 minutes thought because they <i>know</i> there&#x27;s a mistake somewhere, but don&#x27;t need to be bothered finding it.<p>4. &quot;the code author, by virtue of their time and effort, deserves the chance to see their proposals in action&quot;. History is littered with disasters resulting from someone unqualified seeing their proposals in action.<p>5. &quot;Developers are often urged to take more ownership of their work—so why not grant them real authority?&quot; Ownership and authority are not synonymous. Responsible ownership requires, well, responsibility.

Yeehaw! Screw y’all and your lintin’ ‘n’ rules. I gets the final say!<p>Plenty of cowboy developers rejoicing reading this ;)

From the article:<p>&gt; 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.<p>What a shit take. Code reviewers ask questions and point out issues. If your PR includes errors and fails to address problems that reviewers were able to spot just by looking at them, it means nothing how much time you took working on it. Just fix it instead of sulking in blog posts.<p>And then this gem.<p>&gt; 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.<p>What is this? A participation medal? It means nothing how much time and effort you invested. If your PR has errors and introduces obvious bugs and fails to comply with anything, just fix it. Push a commit that addresses remarks and learn from it. Or are you expecting your team members to post follow-up commits to fix the mess you are making? Perhaps you&#x27;re just hoping to block pipelines when automated tests fail?<p>Absurd.

&gt; I hold the (sometimes controversial) view that no developer—or any worker, for that matter—should be forced or coerced.<p>I hold the same view. If you go just a little further with this (&quot;people&quot; instead of specifically &quot;workers&quot;), you arrive at anarchy.<p>That said, what a ridiculous idea. Approving your own work is a known anti-pattern, and it has nothing to do with hierarchy or coercion.<p>&gt; since code changes are reversible<p>Nothing is more permanent than a temporary solution. Also, depending on the program, your code could actually be putting people at risk (e.g. adding a security bug in Firefox or something like that). Sure it might be reversible, but maybe it won&#x27;t be reversed for a long time.<p>&gt; ...deserves the chance...<p>No. If it&#x27;s wrong it&#x27;s wrong. You&#x27;ll feel prouder of your work if it&#x27;s correct than if you just be allowed to do any old mediocre thing. It&#x27;s like a child getting excited about &quot;helping&quot; when all they did was ruin the food and make more work for the adults.