I love pull requests. We do PRs for two line charges. They are part of the QA process and release process. We code review everything, especially those two liners. Code review is non-adverserial. If you can't check your ego, you're not going to work out, sorry.

This is a misleading framing:

> Should you do code reviews at all? Interestingly, some say no, you shouldn’t.

Advocates of pairing compare it to "continuous code review" (1) . This post brushes over that well-known insight, and so does not discuss which _kind_ of code review is most effective: after the fact (the PR model) , 1 on 1 in real time (the pairing model) or group in real time (the "mob" model). Article does mention "cycle time" but what could be lower cycle time than "done at the same time" ?

I'm not assuming which is best, but it's not entirely honest to categorise only 1 of these 3 as actually having code review.

Article talks bout metrics tools, but honestly if this is more important to you than the code and the people, then you're not being agile (2)

1) https://www.pluralsight.com/tech-blog/continuous-code-review...

2) https://agilemanifesto.org/

As an aside, what's with everyone creating these discord servers for their communities. A chat server seems so bad for long term knowledge storage.