This is an interesting read and I'm glad to see that the closing paragraphs emphasize the need for each team to evaluate their own needs. That said, for me it all comes down to the definition of "best product" in this statement:
"They all want to build the best product in the shortest time possible"
From my perspective, the "product" is not limited to what customers see or the code itself. It's the set of outcomes from the code being written and executed. For example... Do other engineers understand the code? Can they support it efficiently? Does it fail gracefully? What is the impact of failures? Are failures automatically detected? Does it lead to security breaches? Did the code author learn things they could do better that they didn't know to ask about? Did other engineers learn from reading the code or asking questions? Are customer requirements satisfied? How much is customers' trust impacted by failures, bugs, and feature that don't meet requirements? How big is your cloud provider bill? Etc...
If the priority is quickly delivering and iterating on features that satisfy customers' needs AND engineers will be supporting their own code, then the "No Code Review by Default" approach has its merits. In fact, I have personally found this approach to work well on constrained, isolated pilot projects where the priority is to unblock key scenarios for a limited set of customers and/or learn about customer needs before building a the "real" solution.
For anything else, I would suggest following the author's own advice: "ask yourself if the circumstances of others apply to you".
There is data on the flu and COVID-19 from parts of the world that are in summer vs. winter. As the situation evolves further this data should enable making a better educated guess:
Houses close together in an urban environment reduces risk rather than increasing it. For example, Redding Electric Utility (REU) and Sacramento Municipal Utility District (SMUD) did not shut off power to the cities they service while PG&E, which services areas outside each of those cities, did. SMUD talks about urban areas being low risk at https://www.smud.org/en/In-Our-Community/Safety-Tips/Wildfir....
"They all want to build the best product in the shortest time possible"
From my perspective, the "product" is not limited to what customers see or the code itself. It's the set of outcomes from the code being written and executed. For example... Do other engineers understand the code? Can they support it efficiently? Does it fail gracefully? What is the impact of failures? Are failures automatically detected? Does it lead to security breaches? Did the code author learn things they could do better that they didn't know to ask about? Did other engineers learn from reading the code or asking questions? Are customer requirements satisfied? How much is customers' trust impacted by failures, bugs, and feature that don't meet requirements? How big is your cloud provider bill? Etc...
If the priority is quickly delivering and iterating on features that satisfy customers' needs AND engineers will be supporting their own code, then the "No Code Review by Default" approach has its merits. In fact, I have personally found this approach to work well on constrained, isolated pilot projects where the priority is to unblock key scenarios for a limited set of customers and/or learn about customer needs before building a the "real" solution.
For anything else, I would suggest following the author's own advice: "ask yourself if the circumstances of others apply to you".