This is wrong. Code review is not for "asking". It has many benefits that the author is missing: 1. Get extra eyes on a change. 2. Learn from your colleagues'

This is wrong. Code review is not for "asking". It has many benefits that the author is missing: 1. Get extra eyes on a change. 2. Learn from your colleagues' thoughts on the work. Honestly, the most important ones may be 2. Almost everything I've learned as a software engineer comes from thoughtful code review comments left by the skilled colleagues with whom I was lucky to work (back when my company was more desirable!) I wish the same benefit on every other aspiring software engineer out there. This article threatens to disinherit them and deny them that source of learning. But it's not just less experienced engineers who benefit from thoughtful comments on all substantial PRs; we all do. I never want to work somewhere that discourages code review like this. To prevent code review causing slowness there's a simple rule: everybody does their code review as top priority. It is true that PRs can make inexperienced engineers think it's ok to open a PR a branch that they haven't carefully tested and that isn't ready to ship. Unless they mark it as WIP, that's not acceptable, as the article correctly says. So, you have to educate people there.