Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No code reviews by default

raycast.com

Post reply on HN
Print view View original

31–40 of 315 posts

Re: No code reviews by default

#31

Post by alkonaut »

ljm wrote: post #14
tus666 wrote: post #7

He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…

If something hit production and caused a major fuck-up because there was no peer review process, then in all the places I've worked at the first action item in the post-mortem would be "we should introduce peer review." Otherwise someone would ask how we could ensure it wouldn't happen again, and no one would be able to say "because we trust them," and leave it at that. It would sound more like "I trust you will neve…

Exactly. I want my code peer reviewed partly because it makes it clear and formal that while we succeed as a team we also fail as a team. It’s much easier to talk about failures when a failure doesn’t have a single person attached to it.

Re: No code reviews by default

#32

Post by jeffbee »

Puts wrote: post #15

This can not be posted too many times. https://www.youtube.com/watch?v=4XpnKHJAok8 Linus Torvalds talk on Google about how GIT is more a way of working then a piece of software. Everybody commits upwards in a tree of trust. If you do it this way you get automatic code reviews and in any team someone should be responsible for the "product" anyway and highest up in the hierarchy.

It's a great example of how Linus has a massive blind spot for the failings of the git model. He's "sorry" they use Perforce. Git is "better than everything else out there" but he doesn't mention Perforce. And yet, the Perforce model is the one that got Google to be one of the fastest-moving organizations on the planet, with the biggest code base.

Re: No code reviews by default

#33

Post by renewiltord »

Most small tech companies probably operate in this manner. We do, too. The practice is that devs do want a second pair of eyes on the code since they want other people to detect flaws in their assumptions or choices before there is pain.

If I'm doing something trivial, I might just push to `master`. For instance, I don't run tests on a `README.md` change.

Interesting to encode it explicitly, though. Strong culture choice, for sure. And probably well suited to their product since they are probably all dogfooding `master` and pushing only periodic tags off it.

Re: No code reviews by default

#34

Post by Someone1234 »

When my code has been code reviewed I've had bugs found, improvements made, and edge cases brought up. I genuinely believe my code is better for having been reviewed, and I work harder on the quality of my code because it is going to get reviewed.

Now, code reviews aren't a panacea, there's an awful lot of bike-shedding going on (in particular whenever interfaces are reviewed) but they're a net positive in my view. It isn't about trust, it is about creating a quality product, along with postmortems (an under-utilized philosophy) and automated tooling (inc. testing, validators, etc).

Re: No code reviews by default

#35

Post by jaredsohn »

jolux wrote: post #29
ljm wrote: post #14

Earlier quoted context omitted.

If something hit production and caused a major fuck-up because there was no peer review process, then in all the places I've worked at the first action item in the post-mortem would be "we should introduce peer review." Otherwise someone would ask how we could ensure it wouldn't happen again, and no one would be able to say "because we trust them," and leave it at that. It would sound more like "I trust you will neve…

Causing a major fuck-up in production is probably also a sign that you need better release validation and deployment practices.

For many developers, people merge their branches directly to production so the pull request review is where that checking happens.

Re: No code reviews by default

#36

Post by larsrc »

Apart from the other reasons for code reviews already mentioned, there's this: an inexperienced developer (in a particular area) may not _know_ when a code review is appropriate. A change that looks innocent may have wider consequences than expected. Code reviews spread knowledge, and knowledge is the true output of software engineering.

Re: No code reviews by default

#37

Post by Abroszka »

yupper32 wrote: post #10

> Pull requests don't prevent bugs. Is this some anti-vax satire? Of course pull requests (code reviews) reduce bugs. And of course some slip through. It doesn't need to be 100% to be useful.

I haven't seen any research that supports either. I wouldn't be surprised to learn that code review does nothing other than share knowledge, or to learn that it reduces bugs by 50%. I just honestly have no idea, I do code reviews, because we do code reviews.

In fact I have seen alarmingly little research about code management. Code review, standup, agile, etc. does any of it do anything useful? I only came across anecdotal evidence which can be dismissed.

Re: No code reviews by default

#38

Post by erpellan »

tus666 wrote: post #7

He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…

That final, 1 word sentence is one of the major problems of PRs. An engineer might spend several hours really thinking through a problem, talking with colleagues, whiteboarding options and coming up with a workable solution that addresses all the obvious issues and a bunch of non-obvious ones.

Only for a drive-by take-down by someone with none of the context. It's a totally asymmetric investment of time. Even helpful review comments might only take a minute to write but a day to incorporate.

Re: No code reviews by default

#39

Post by AnimalMuppet »

tus666 wrote: post #7

He mentions "trust" a lot. Is that why we do code reviews, because we don't trust each other? I find this attitude problematic. We do code reviews because humans make mistakes. Requirements can be misinterpreted. Different work in progress can be in conflict with each other. Reviews are a good way to learn from each other and keep abreast of what work is occurring outside your own bubble. Not doing code reviews becau…

It's worse than that. I don't trust me. You shouldn't either. I need the review.
Post reply on HN