> 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.
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.
And then this gem.
> 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.
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're just hoping to block pipelines when automated tests fail?
> I hold the (sometimes controversial) view that no developer—or any worker, for that matter—should be forced or coerced.
I hold the same view. If you go just a little further with this ("people" instead of specifically "workers"), you arrive at anarchy.
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.
> since code changes are reversible
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't be reversed for a long time.
> ...deserves the chance...
No. If it's wrong it's wrong. You'll feel prouder of your work if it's correct than if you just be allowed to do any old mediocre thing. It's like a child getting excited about "helping" when all they did was ruin the food and make more work for the adults.
Yeehaw! Screw y’all and your lintin’ ‘n’ rules. I gets the final say!
Plenty of cowboy developers rejoicing reading this ;)
From the article:
> 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.
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.
And then this gem.
> 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.
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're just hoping to block pipelines when automated tests fail?
Absurd.
> I hold the (sometimes controversial) view that no developer—or any worker, for that matter—should be forced or coerced.
I hold the same view. If you go just a little further with this ("people" instead of specifically "workers"), you arrive at anarchy.
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.
> since code changes are reversible
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't be reversed for a long time.
> ...deserves the chance...
No. If it's wrong it's wrong. You'll feel prouder of your work if it's correct than if you just be allowed to do any old mediocre thing. It's like a child getting excited about "helping" when all they did was ruin the food and make more work for the adults.