Trust, but verify.
Ask HN: Does "trust" eliminate the need for code reviews?
31–40 of 77 posts
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#32I'm going to (generously) assume that author means to immediately merge into a development or feature branch and review later before merging those commits somewhere else.
If so, sure that probably saves time. Most reviews should be uneventful anyway and it broadens the scope of review to the whole branch. That's helpful when you have lots of moving parts and multiple devs working on the same feature.
My opinion on this is that code review must occur especially if there is no other form of review. That's usually more technical projects where the devs are left alone. Contrary to popular belief there really are some projects so short-lived, truly throwaway code such as light web dev (marketing pages and whatnot), that final proofreading and QA are good enough.
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#33No.
Sometimes speed for speed's sake is a bad idea.
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#34Test first, review later. A quick skim of the code with a live test in some staging environment before merging is good enough
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#35The point of peer review is not to debug others' code (sometimes it helps and that is welcome). The point of peer review is to ensure the change adheres to team standards - both technical and design - as well as to give a chance for domain knowledge share. With that in mind, trust is a foundational aspect of peer review, just not in the way you mentioned.
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#36To everyone responding “no”: how certain are you that your colleague didn’t just skim your +5,000/-5,000 patch and slammed down an LGTM in the comments? Okay, maybe they put a few nitpicks in to make it seem like they looked closely.
You still have to trust your team to actually do reviews.
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#37If you're not going to review the code before merge, then you certainly aren't going to review it after it's been merged. It's one of the reasons that I write my tests before the code, I know that if I write the code first then I'm less likely to write any tests for it.
[deleted]
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#38It depends. A lot . I work with people I do "trust" and my code-review is usually "LGTM" -- often without even looking. Most code doesn't go right to production and can be fixed if there are bugs (which I'm unlikely to find by looking at it, anyway.) The things I look at are things that are hard to change in the future: big architectural decisions, schema (db and data format) changes and things like that. More junior…
you get nitpicks on 2000 LOC I find lmao
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#39We should trust engineers when they deem their own minor pull requests as not requiring review.
i.e. trust engineerings ability to judge their PR as trivial.
This requires trusting good intent (which I think is healthy), and trusting their self awareness.
Re: Ask HN: Does "trust" eliminate the need for code reviews?
#40It depends. A lot . I work with people I do "trust" and my code-review is usually "LGTM" -- often without even looking. Most code doesn't go right to production and can be fixed if there are bugs (which I'm unlikely to find by looking at it, anyway.) The things I look at are things that are hard to change in the future: big architectural decisions, schema (db and data format) changes and things like that. More junior…
you get nitpicks on 2000 LOC I find lmao
[deleted]