Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews.
Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.
There didn't use to be any mention of pre-merge reviews in that website. In fact, the text in the website used to be pretty emphatic against any branching whatsoever.
I have known and worked with Steve Smith (the only "friends" mentioned in the website [0] - hi Steve! :D ) for years and we had many discussions about the merits of short-lived branches for peer review. Myself and a few others have argued that you can have pretty much all the benefits they were looking for with TBD without the draconian "always push to trunk" rule. It just takes a bit of discipline and communication, but to be honest I think the draconian one needs even more of those if it is to succeed.
I'm happy that the website has been updated since (it's been at least a few months, maybe even a couple years) to acknowledge and "allow" that strategy.
Post-merge reviews obviously help with the same goal of having very little work stuck in WIP. But it's a 80/20 kind of goal, not all or nothing. Post-merge reviews are probably only worth it when you can trust the developers to not screw up too much and to broadly agree on quality standards.
I spent quite a while trying to find the post and comments but came up empty. Am kind of hoping the same person will pop up here, as they seemed extremely passionate about pointing it out.
Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.