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

61–70 of 315 posts

Re: No code reviews by default

#61

Post by ReleaseCandidat »

dan-robertson wrote: post #9

I’m curious how they avoid pushing changes that break the build. Maybe they have some other reason that this doesn’t happen or is hard but having a large number of people trying to collaborate on a constantly broken repo is not a recipe for productivity. I also wonder if there are typically 0 reviews or typically 1 — that is, are people even reading their own changes before they push them.

> I’m curious how they avoid pushing changes that break the build.

By not pushing changes that break the build. In other words: that does not work if you can't test (actually test, not just try to build) your code before pushing it to main.

Re: No code reviews by default

#62

Post by Clubber »

watwut wrote: post #46
geuis wrote: post #18

Absolutely not. This is a recipe for disaster and a terrible example to set for any upcoming engineers that haven’t had much industry experience yet. Code reviews help me be more confident in my own work. Even if 90% of the time it’s fine, there’s always that 10% where a second pair of eyes catches a mistake or offers a suggestion that makes the code even better.

> there’s always that 10% where a second pair of eyes catches a mistake or offers a suggestion that makes the code even better. Testing is pretty awesome process to find bugs.

QA departments are expensive. Execs in their infinite wisdom opted to dump that task on developers who earn 3x as much as QA people. Synergies!

Re: No code reviews by default

#63

Post by Abroszka »

buttersbrian wrote: post #56
Abroszka wrote: post #37

Earlier quoted context omitted.

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 ane…

I think pull requests are synonymous with code-reviews here. I think it is unquestionable that code-reviews catch bugs. Its value as a use of time is another question.

> I think it is unquestionable that code-reviews catch bugs.

Yes, it does catch some, but does it catch more than no code review? There is no point in catching bugs if it also creates bugs to catch.

Re: No code reviews by default

#64

Post by [deleted] »

jeffbee wrote: post #32
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.

[deleted]

Re: No code reviews by default

#65

Post by yupper32 »

Abroszka wrote: post #63
buttersbrian wrote: post #56

Earlier quoted context omitted.

I think pull requests are synonymous with code-reviews here. I think it is unquestionable that code-reviews catch bugs. Its value as a use of time is another question.

> I think it is unquestionable that code-reviews catch bugs. Yes, it does catch some, but does it catch more than no code review? There is no point in catching bugs if it also creates bugs to catch.

Sorry, are you saying that it's possible that code reviews cause more bugs than they solve?

That's absurd...

Re: No code reviews by default

#66

Post by canyonero »

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.

Yeah -- I LOLed at this one because I've caught at least hundreds, maybe thousands of bugs during review on pull requests.

It's weird and silly to expect prevention with tool that is not designed to prevent. Peer review (and the PR model) exists as quality control tool for many different aspects of someone else's work.

Re: No code reviews by default

#67

Post by ReleaseCandidat »

brokencode wrote: post #49
klabb3 wrote: post #19

Earlier quoted context omitted.

The idea is not that everyone has to be omnipotent, it's that you trust people enough to send for review and ask for help when appropriate , instead of always. I.e. when you're new to the code base or language.

I don’t think I’ve ever reviewed code from a new hire that didn’t have multiple problems or style issues that needed to be addressed. That’s also actually true for code from most experienced devs too. And it’s rare for my code to get through code review with no issues found. So bottom line, I just don’t think this would work for most teams and developers.

> I just don’t think this would work for most teams and developers.

Most teams and developers don't do code reviews because the only person that could do code reviews would be the developer himself.

Re: No code reviews by default

#68

Post by notmyfuture »

For a small team of capable engineers, working on something that has low consequence for any single change failing plus a strong business motivation to move fast: sure, do without code reviews if you want.

There is no universal "best practise" for building software, there is just whatever works best for your context. Practices can, and should change as your business context does. There are some things that are net beneficial for a team in the majority of situations though, I'd consider code reviews one of these things and make that the default.

Re: No code reviews by default

#69

Post by buttersbrian »

Abroszka wrote: post #63
buttersbrian wrote: post #56

Earlier quoted context omitted.

I think pull requests are synonymous with code-reviews here. I think it is unquestionable that code-reviews catch bugs. Its value as a use of time is another question.

> I think it is unquestionable that code-reviews catch bugs. Yes, it does catch some, but does it catch more than no code review? There is no point in catching bugs if it also creates bugs to catch.

If it catches ANY bugs it is objectively better than no PR/code-review from a bug standpoint. Unless you're arguing that pr/code-review creates more bugs than it solves?

Again, I think the question is value. Is a dev's time best used in code-review vs. something else? It's almost certainly the case that time is better spent elsewhere depending on the develop and needs or the organization.

Re: No code reviews by default

#70

Post by kps »

erpellan wrote: post #38
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…

> Only for a drive-by take-down by someone with none of the context.

Then write it down. If the code reviewer can't follow what's going on, what hope is there for the new hire looking at it six months from now?

Post reply on HN