Hacker News new | ask | show | jobs
by danpalmer 864 days ago
There are two ways of looking at this, I think the author took the positive way, and you've taken the negative.

You could argue that shorter PRs are easier to review and therefore people are doing more review, and that should result in better changes (indeed the 15% fewer reverts supports this).

Or you could argue that shorter PRs are harder to review as they have less context, and therefore more time is taken but that a better output is not necessarily being reached.

I think both of these are entirely plausible, and the truth probably depends on other process factors.

1 comments

It is also going to be more reverts.

If you split 200 lines of code into 4 x 50 you are actually going to have 0.85 x 4 reverts or 3.4x reverts with this strategy.

But overall the whole data is terrible and infuriating because likely the changes are very different in the dataset depending on the loc.