733
Merge then review (programming.dev)
submitted 2 years ago* (last edited 2 years ago) by [email protected] to c/[email protected]

Move fast and break things.
Merge vulnerabilities.
Double the work.
Merge code without tests.
Anything, but don't let code become stale.

(page 3) 48 comments
sorted by: hot top new old
[-] [email protected] 3 points 2 years ago

I wonder how many programmers out there have intentionally set out to subtly sabotage the system. Anyone doing that, good luck to you.

[-] [email protected] 3 points 2 years ago

You guys review?

[-] [email protected] 2 points 2 years ago

This explains what is going on a facebook.

[-] [email protected] 2 points 2 years ago

@agilob code is like wine. You let it out in the cold and it gets better over time by itself.

[-] [email protected] 1 points 2 years ago

The subtle Linux-flex in the screenshot.

[-] [email protected] 1 points 2 years ago* (last edited 2 years ago)

That's nice but it goes against our quality standards and the international quality standards we are charging the client extra for adhering to, the line you're trying to merge into is stability and needs CCB approval for the merge, and the client has specifically requested only showstopper-level bugs be addressed for stability lines. You know what, I have neither the time nor the crayons to properly explain this to you, a consultant that supposedly knows the business. Pack your shit, you're gonna have a wonderful time posting this crap on LinkedIn instead. #gitshiton

2 days before, at Pete Hurrd former job

[-] [email protected] 1 points 2 years ago

It can work if you have a test zone and only a small amount of people work on a given code base.

Also checks to ensure the code compiles and tests pass before merging, as some quality gateway.

[-] [email protected] 1 points 2 years ago

Probably unpopular opinion, but peer reviews are overrated. If coders are good AND know the project, the only thing you can do in a PR is nitpicking. They are more useful for open source collaborators because you want to double-check their code fits with the current architecture. But people here are reacting as if peer reviews could actually spot bugs that tests can't catch. That happens rarely unless the contributor is junion/not good.

[-] [email protected] 3 points 2 years ago

Nitpicking can be automated by a linter, then reviews can actually sit back and review more important things like high-level design and scalability

as if peer reviews could actually spot bugs that tests can't catch

There can't be bugs if there are no tests to catch them! Ofc you can also automate test coverage standards. But PRs are sometimes the only way to catch bugs, even and especially with senior devs in my experience bc they are lazy and will skip writing tests, or write useless or bare minimum tests just to check off code standards and merge on ahead

[-] [email protected] 1 points 2 years ago

If coders are good AND know the project

Those are some pretty big ifs.

[-] [email protected] 1 points 2 years ago

Code review can't fix incompence though. I lost count of how many times my boss told me "review that PR well because X is not very good". Also my point is that they are overrated, not that they are useless.

load more comments (2 replies)
load more comments
view more: ‹ prev next ›
this post was submitted on 14 Nov 2023
733 points (97.0% liked)

Programmer Humor

23995 readers
1202 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

founded 2 years ago
MODERATORS