I am definitely guilt for that, but I find this approach really productive. We use small bug fixes as an opportunity to improve the code quality. Bigger PRs often introduce new features and take a lot of time, you know the other person is tired and needs to move on, so we focus on the bigger picture, requesting changes only if there is a bug or an important structural issue.

[–] NocturnalMorning@lemmy.world 47 points 4 months ago (2 children)

I always try to review the code anyway. There's no guarantee that what they wrote is doing what you want it to do. Sometimes I find the person was told to do something and didn't realize it actually needs to do Y and not just X, or visa versa.

[–] ScampiLover@lemmy.world 20 points 4 months ago (1 children)

I like to shoot for the middle ground: skim for key functions and check those, run code locally to see if it does roughly what I think it should do and if it does merge it into dev and see what breaks.

Small PRs get nitpicked to death since they're almost certainly around more important code

[–] derpgon@programming.dev 10 points 4 months ago

Especially when you see a change in code, but not in tests ☠️

[–] souperk@reddthat.com 2 points 4 months ago (1 children)

Yes, I always review the code, just avoid nitpicking the hell out of it.

[–] NocturnalMorning@lemmy.world 1 points 4 months ago

Yeah, sorry, totally misread your comment.

[–] breakingcups@lemmy.world 2 points 4 months ago (1 children)

So you're always behind, patching up small bits of code that don't comply with your guidelines, while letting big changes with, by deduction, worse code quality through?

[–] souperk@reddthat.com 3 points 4 months ago

Not really, we are a small team and we generally trust each other. Sure there are things that could have been better, but it's not bad either.