this post was submitted on 14 Nov 2023
708 points (96.9% liked)

Programmer Humor

19331 readers
74 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 1 year ago
MODERATORS
708
Merge then review (programming.dev)
submitted 11 months ago* (last edited 11 months 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.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] -1 points 11 months ago (5 children)

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 11 months 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

load more comments (4 replies)