[boomlinde]

I don't necessarily see code reviews as the problem here. I think it's a very important aspect of development that unfortunately seems first in line to get cut back when other parts of the organization fail, when for the sake of quality I believe that the organization should be designed to always accommodate it.

For example, you mention waiting until the last minute and throwing away work. If this is such a big deal, maybe the units of work are too big or too loosely defined. Loosely defined as in "eh, we never needed this in the first place" or big as in "sorry about that but your 2000 LOC commit just isn't the right approach". Maybe github style reviews/pull requests are also not the best way to go about it. IMO the github style is pretty weird and shouldn't be conflated with reviewing in general.

At my current workplace, we use gerrit to review every commit. The only way that they'll ever get to master or a shared development branch is if they get a +2 vote. Maybe this is closer to a "managed push"? It's not rare that someone finds an issue, and when that happens it's very rare that it means scrapping the entire patch, and when that happens, it's usually a very small patch for a problem/feature that ended up being fixed elsewhere, so I definitely don't think it's a waste of time. Instead I am grateful that many of the patches didn't enter the codebase in their initial state.