Find Sandjiv at: www.linkedin.com/in/sandjiv/

Find mathieu at: www.linkedin.com/in/mathieu-s...

The times I have managed to convince people to give the higher echelons a shot, I have always been positively surprised at the outcome.

But there is quite a strong inertia pushing towards scatter/gather approaches and individual, rather siloed work with a PR as a deliverable.

The times I have managed to convince people to give the higher echelons a shot, I have always been positively surprised at the outcome.

In order of preference:
- Teaming/swarming
- Pairing always/most of the time
- TBD, small commits, tested, with feature branches, continuously pushed to main
- Ship show ask
- Collaborative reviews
- Async reviews

Lastly, I gear my effort and optimizations toward improving the flow of one piece of work, PRs are on the way of that.

- We are a collaborative industry that would rather stare at a screen on our own, in chase of individual flow.

But, I acknowledge that:
- Pair/ensemble all or most of the time is scary for a lot of people
- Pair/ensemble can be tiring (it also can be uplifting)
- We, as an industry, in general have trouble with interaction.

If I could choose everything, I would use a swarming/teaming strategy, with trunk based development . Reviews are done on the spot, by multiple people and ideas and alternatives are all tested/codes before choosing the correct one.

At the very least I would advocate for a a ship/show/ask strategy. I would also encourage to do all review synchronously, as a Pair exercise.

Also, all of those are better alleviated with training and upskilling than by PRs (which I don't think are really geared for learning).

Catching bugs and defects by having a tired set of eyes that would rather be doing the job they will be judged by (most times) rather than reading other people's code is wishful thinking, which I believe is caused due to survivors bias.

With regards to code quality, bugs, defects, etc. I don't believe PRs are a good vehicle either. Code quality is super subjective, although it can allow a measure of 'control' to have PRs.

On top of that, and I agree that learnings can be found in the most unsuspecting places, I don't think most PRs will teach anything. Although some do.

Now, granted, you can ask the PR submitter to create an elaborate document, with a top down view and an explainer of the highlights, but that means time and effort (and a 'paused' feature). And that might alleviate some of it.

I also believe, but this is quite personal, that PRs are a dreadful vehicle for learning, the tools we have to review code are not geared towards learning, but rather towards line by line analysis.

That handoff now has at least two queuing times (if all goes well) one for pick-up one for merge/response. Merging before the PR does alleviate this, but still leaves at least one handoff and queue, in the optimal case.

Reviews are a handoff at least, if everything goes well. We are (I am?) pathologically incapable of not picking up the next task, what is worse, we are encouraged to take the next task.