this post was submitted on 02 Jul 2024
926 points (98.5% liked)
Programmer Humor
18961 readers
1015 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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
Especially when you see a change in code, but not in tests โ ๏ธ
Yes, I always review the code, just avoid nitpicking the hell out of it.
Yeah, sorry, totally misread your comment.
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?
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.