I agree. I think the author is projecting an opinion of "I don't want to do code reviews" so is justifying that opinion by outlining a process which allows him to bypass reviews in majority of cases.
My own opinion: do code reviews. They are a good thing. However if you don't want to or cannot make all the suggested fixed before merging then put the comments into s new ticket for later and move on. Just don't skip the process and lose that chance to have a record of any technical debt you've incurred.
> I think the author is projecting an opinion of "I don't want to do code reviews" so is justifying that opinion by outlining a process which allows him to bypass reviews in majority of cases.
I thought that too. The author seems to came up with the whole "Ship/ Show/ Ask" strategy so that it looks like their team actually follows a process instead of just plain skipping on doing code reviews.
While I can relate to their motivation to go without code reviews:
> Sometimes Pull Requests sit around and get stale, or we’re not sure what to work on while we wait for review...
> We also get tired of the number of Pull Requests we have to review, so we don't talk about the code anymore. We stop paying attention and we just click “Approve” or say “Looks good to me”.
These problems are very real and take time and effort to address. I just don't think opting out of reviews is a good way to solve them.
Well, the team I'm on accepts what the blog post calls a Show PR in a rare occasion when something has to be fixed right now. E.g., the prod is down kind of situation. We still go through a review but don't wait for approvals to merge and if there is any feedback we deal with it later.
> My own opinion: do code reviews. They are a good thing.
Being a solo dev at the moment, I sorely wish I had someone to review my changes. Have only had one major mistake slip through in ~2 months (and it wasn't a bad one) but still, someone else could have caught that.
I'm sure you could hire someone to help (without googling I'm willing to be pr-as-a-service exists) , but you'd end up being unable to call yourself a solo dev!
Oh, sorry, I should clarify - I'm working for a company that are having trouble hiring and retaining backend devs which is why I'm the only one here atm.
It is normal to accept that it broke something and simply push a fix instead of rolling back. Once something is "out" a rollback can significantly complicate things both internally and externally for the end users.
My own opinion: do code reviews. They are a good thing. However if you don't want to or cannot make all the suggested fixed before merging then put the comments into s new ticket for later and move on. Just don't skip the process and lose that chance to have a record of any technical debt you've incurred.