Live data from Hacker News

Ask HN: Does "trust" eliminate the need for code reviews?

news.ycombinator.com

11–20 of 77 posts

Re: Ask HN: Does "trust" eliminate the need for code reviews?

#11
No, of course not, everyone makes mistakes.

But also the point of code review is not just to catch mistakes, suggest improvements, etc, but as a way to learn and keep up-to-date with the code base, and also to pick up tips or whatever from other developers.

And I guess a meta-point is it's one of a number of practices that makes the team a team.

Re: Ask HN: Does "trust" eliminate the need for code reviews?

#12
It’s not about trust.

It’s about risk management, communication and teamwork.

Development at scale is a team sport. There’s a difference and it’s simple starting with…

- Does my team understand this change?

- Is there anything I missed that would have a negative impact on others?

Re: Ask HN: Does "trust" eliminate the need for code reviews?

#13
It 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 and newer people, I tend to look more closely and give more advice.

Personally, I get annoyed when people feel they need to critique something to make it clear they reviewed the code. In most cases, the feedback I get from reviewers is not consequential -- and just slows things down. But I have certainly had cases where the reviewer made great points and I changed the code to fit.

Re: Ask HN: Does "trust" eliminate the need for code reviews?

#14

No. I trust myself. I still want someone to review my work. If nothing else than to essentially catch typos. You can’t proofread your own output.

It’s not about trust.

It’s about risk management, communication and teamwork. Development at scale is a team sport.

There’s a difference and it’s simple starting with…

- Does my team understand this change?

- Is there anything I missed that would have a negative impact on others?

Re: Ask HN: Does "trust" eliminate the need for code reviews?

#17
Depends so much on so many things. Like, what kind of app/company are you building? How big is the company/app/team(s)? Who is on your team? What are your other practices? Etc..

For example, if my team was very junior, I'd be less inclined to merge first, but if it was very senior, I'd be more inclined. But even then, it depends on other factors.

Re: Ask HN: Does "trust" eliminate the need for code reviews?

#18
To me, there are two main reasons to review code (before merge): quality and trust. Quality should come way before trust, because if you don't at-least-mostly trust contributors then there's something wrong that code review won't fix. And if you think anyone is likely to go back and review already-merged code for quality when your manager is pushing for "velocity" (especially as it probably works, to some extent), well, you're probably wrong.

If you think you can deal with the quality hit then yeah I guess just go crazy, spurt out another buggy pile, just don't bother me about it.

Post reply on HN