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

91–100 of 315 posts

Re: No code reviews by default

#91

Post by marcosdumay »

Clubber wrote: post #62
watwut wrote: post #46

Earlier quoted context omitted.

> 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!

> who earn 3x as much as QA people

And never learned how to properly test software... Or earn 10x as much and consider it not a priority.

Re: No code reviews by default

#92

Post by dovetailed »

Abroszka wrote: post #37
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 ane…

No post body was provided.

Re: No code reviews by default

#93

Post by AlfeG »

ReleaseCandidat wrote: post #61
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.

Is there anyone on the planet, that always run all tests locally even for last second minor change that definitely will not break a build?

Especially funny for distributed around globe teams. When You spent half a day fixing a build issue from the "night" workers. Have eat a lot of this.

Re: No code reviews by default

#94

Post by zzzeek »

so they didn't like github PRs so...they ditched code review altogether? how strange and sad. there's lots of tools that can be used for code reviews that don't have any bearing on whether or not you also use github for source control.

We at the SQLAlchemy org actually have Gerrit integrated with Github PRs so you can use both UXes for the same patch at once, and other orgs do this too.

Re: No code reviews by default

#95

Post by curious_cat_163 »

that_guy_iain wrote: post #86

> Pull requests don't prevent bugs. I remember once I was giving a talk on code review and I said that code review doesn't prevent bugs and people were shaking their heads. Everyone hangs on to this one thing, but if you look at the majority of pull requests that have been approved you'll see a lack of comments about pontential bugs. Also, if you do see a comment about bugs they'll often be disregarded. This drives m…

> I think the biggest problem with code reviews is it often becomes adversarial and people want to come out on top.

Is that really a problem with code reviews? Or, is that a cultural issue for a given team?

Re: No code reviews by default

#96

Post by sanderjd »

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…

Yes, catching mistakes (which everyone makes) and bidirectional communication are the points of code reviews, it's not a lack of trust.

Re: No code reviews by default

#97

Post by curious_cat_163 »

Code reviews help. However, it is unclear to me if PRs are the best way to do them. I often find a walkthrough on a screen share a lot more helpful to receive/give feedback. It also ends up saving time. The downside of this approach is that it has to be synchronous.

Re: No code reviews by default

#98

Post by sanderjd »

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…

Is this a common practice? I've never worked under a code review process where the accept / reject decision was being made by "drive-by" reviews from "someone with none of the context". It has always been team members with a lot of context reviewing each others' code.

Re: No code reviews by default

#99

Post by sanderjd »

watwut wrote: post #44
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…

The best code I have seen was on projects without code review. And projects with it were more mess - they were surface consistent but overall hard to comprehend. The deciding factor was ownership and accountability tho - you maintained own code and if you done it crappily, you knew. The code review is related to assumption that everyone can change everything - meaning all in all inconsistent mess. It is also related…

This is the exact opposite of my experience.

Re: No code reviews by default

#100

Post by ipaddr »

whoomp12342 wrote: post #59
mixedCase wrote: post #3

I'm glad this works better for them, or at least they feel that it does. I'd also bet that they're either a small minority of teams that jell so well that they manage to scale a codebase without it turning into a disgustingly inconsistent mess; or that indeed their codebase qualifies as such or is still too small for the effects to be very visible. Code reviews are not a tool intended mainly to catch bugs. Types, aut…

IMO code reviews are a tool for mentorship and keeping architecture in line

They can also be used for bullying, micromanaging and other social constructs
Post reply on HN