Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.
this post was submitted on 14 Nov 2023
726 points (97.0% liked)
Programmer Humor
19594 readers
815 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 kind of with the sentiment. Review pre merge though, but only block the merge if there are serious faults. Otherwise, merge the code and have the author address issues after the merge. Get the value to production
Ugh, not this SAFe Agile (tm) cultist bullshit. The "value" is working, bug free code, which you get when you put it through review and QA before it gets to production.
There's often features and bug fixes worth more than the ones introduced in the PR. I've yet to see bug free code just because it's went through review and QA.
Surely you've seen bugs caught because code went through review and QA though. Those are bugs that would go into production if following the "advice" in this post.
I'm saying identify the bugs through review, and fix them. Just do it in a new PR unless they are critical