[Joker_vD]

> If management is measuring pull request (PR) throughput, is it really so bad that developers start pushing through smaller PRs?

So, just the previous week I've made 5 small PRs, all of them working on the same certain "area" of the code base but different pieces of it. Two of those PRs touched almost every single corner of that "area" (differently structured error reporting and differently formatted logging) another one had a rather sizeable refactoring and code movements between three major files of that code area, and as for the two remaining ones, one absolutely depended on the other but could not be done in the same PR because of how the JIRA issues were structured (i.e. "PROJ-9004: Make it do foo", "PROJ-9005: While foo from PROJ-9004 is happening, make it also do bar").

I've also made a decision to not order those PRs sequentially (i.e., base the next PR on a previous PR), and instead branched each PR from the dev trunk and went to work on them. As a result, I've increased the work I had to do approximately by 50% because of the merge conflicts I had to resolve. The reviews combined took about twice as much time as a single big review of all five changes in one PR would've probably taken. The QA took about five times as long since QA did full regression of that code area 5 times instead of 1 time; they've also almost missed an error in the 4th pull request because of all the repetitiveness.

All in all, 10/10, recommend it if you need your coworkers to get lost in the maze of similarly-themed little branches, all alike.