[klyrs]

You missed your parent's point: LGTMYOLO is the response to large PRs; where small PRs get bikeshedding.

And this is the classic theme behind bikeshedding. People can understand that small PR at a glance, and there's always multiple ways of doing everything. There's a perverse desire to demonstrate productivity, and nagging at small PRs is a way to do that without a lot of effort; ironically reducing actual productivity, see: Cobra Effect.

That big PR though? Saying something intelligible about it requires serious effort. In a low-skill environment, nobody will touch the PR for fear of demonstrating that they don't know what they're talking about.

I disagree with the premise of the article. The ideal PR is a well-encapsulated unit of work. Sometimes you need to fix a typo or handle an edge case, and you make a 1-line PR. Sometimes you need to add a new module and you add 3 thousand-line files and put little hooks in 30 more files.

[bombcar]

That's exactly what happens. At some point a PR gets too big and the only thing you can do is run the tests, try the functionality, and LGTMYOLO approve it.

You leave it open longer in hopes someone else will look at it, and maybe one or two people look at places they've had issues in the past, but it gets through and blows up spectacularly and those get fixed.

Anyone who says their development is not the above is probably confused or lying ;)

[klyrs]

I've participated in month-long reviews where nobody's time was wasted. That's extremely rare, mind you, but if you're accustomed to low-quality code and a "break shit fast" attitude, you might be inclined to mistake that for a universal rule of software development.

In fact, if you put quality first, the "only thing" you can do with a long PR is actually do the work. And the more accustomed you and your team become with actually doing work, the more productive you'll be.