Sound recommendations, but what if I claimed that code reviews are overwhelmingly a waste of time? At best, they catch a handful of problems that should've been

Sound recommendations, but what if I claimed that code reviews are overwhelmingly a waste of time? At best, they catch a handful of problems that should've been caught earlier, but they are far more likely to create more issues, especially interpersonal ones which are far harder to fix than bugs in code. All code reviews are ultimately criticism and while it's really hard to deliver criticism well in person, it's pretty much impossible to do so in text, even with the best of intentions. A fundamental problem is that code review brings more human factors into the process. You pretty much never want that. Your whole job as a programmer boils down to removing as many human factors as possible. If that idea bothers you, perhaps you're in the wrong profession. Instead, foster a culture of code ownership and responsibility. Assume that an owner can work without reviews, and that a reviewer is not realistically going to be able to improve upon that meaningfully while staying cost positive. This goes against ideas like guarding against "the bus factor". You may consider guarding against the bus factor by occasionally assigning actual programming tasks (not just "code reading") to developers ordinarily working on other things, but those should be focused events, not part of the everyday process of actually getting stuff done. In any case, "bus factor events" are rare and humans are prone to buy overpriced insurance against rare events.