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

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

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 77 posts

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

#61

Post by WirelessGigabit »

dvfjsdhgfv wrote: post #59
WirelessGigabit wrote: post #4

Oof. Difficult one. I've dealt with multiple people and there are some I would blindly trust because I know they would do the right thing. On the other hand I've worked with people who need more reminders (eventually we had to discontinue our relationship) to do the right thing: Does the PR make sense? Did you format the code? Did the tests pass? Did you fix the tests? Or did you just comment them out? And for the pe…

Well, at least these three: > Did you format the code? > Did the tests pass? > Did you fix the tests? Or did you just comment them out? should be obvious from the MR/PR page

Absolutely. But we've had developers who, even with extensive coaching, eventually ended up proposing PRs with the issues above.

Equally, we had reviewers, who, with extensive coaching, (and I see this a lot with contractor teams), allow PRs like this.

I work at a company where I have to speak up. It is ingrained in the way we work.

However, with contractor teams that way of working does not always translate well. They don't necessarily 'dare' to speak up on PRs of their own colleagues.

It's a weird dynamic.

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

#62

Post by cassianoleal »

dkersten wrote: post #43

Code reviews have absolutely nothing to do with trust. If you don’t trust your team members, then the team is inherently dysfunctional. Code reviews won’t fix that. I’m in a team where members have a very high level of trust yet we’re still very strict on code reviews, because it helps catch mistakes, things that were forgotten or makes sure things were thought about. It’s a quality gate as well as a knowledge sharin…

> I’m in a team where members have a very high level of trust yet we’re still very strict on code reviews

In my experience, the more trust there is, the more strict and better the code reviews are. Where there's less trust, there tends to be more lenience.

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

#66

Post by dwb »

swiftcoder wrote: post #42
dwb wrote: post #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), we…

You are on the money, but I think quality is much more subject to automation than trust is. On a previous team, implementing team-wide autoformat-on-save and a decent linter eliminated ~75% of code review feedback overnight. If your code reviews are mostly enforcing cosmetic properties of the codebase, automate that shit. You have similar levers to pull in other areas. Fail the PR if the test coverage drops, add warn…

I mostly agree, and this maybe gets a bit philosophical, but for me true quality needs a human too.

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

#67

Post by RobertHamilton »

Ah, the tangled web we weave... or in my case, the tangled web I discovered on my wife's phone. It all started innocently enough - a casual glance at her screen, a flicker of suspicion, and suddenly I found myself embarking on a journey with Adware Recovery Specialist, a digital detective that would reveal the secret my wife had been keeping from me. It's funny how even the most oblivious among us can sense when something isn't quite right. Little things started adding up - the whispered phone conversations, the sudden evasiveness when I asked about her day, and the mysterious smiles plastered on her face while texting. It was like a puzzle with missing pieces, and my gut told me those missing pieces spelled trouble. Confronting the possibility of infidelity is never easy, and doubt crept in like an unwelcome houseguest. Was I just being paranoid? Should I trust my partner despite these unsettling signs? It took some serious soul-searching before I mustered the courage to seek the truth and put an end to the sleepless nights. Adware Recovery Specialist, my digital confidante in this treacherous journey. With its suite of tools and features, this Adware of a group promised to unveil the hidden secrets residing within my wife's phone. From retrieving deleted messages to tracking her online activities, it seemed like the solution I had been longing for. Adware Recovery Specialist helped me uncover all that my wife was hiding in her phone and I now know where I stand. visit www.adwarerecoveryspecialist.expert today and tell them what you need. You can also email them: Adwarerecoveryspecialist@auctioneer.net

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

#70

Post by alkonaut »

Lutger wrote: post #54
alkonaut wrote: post #26

> merge first, for the sake of high velocity I think what constitutes high velocity or best practice is going to be highly dependent on the context. What's the risk and consequences of a mistake, for example? If you are making some Crud SaaS and you are in an early/startup setting then obviously you can probably correct a mistake pretty quickly. Perhaps you haven't even shipped the product publicly. Worst case a serv…

The OP doesn't state not to review code anymore. I think the most common process is something like: feature branch -> review -> merge intro trunk -> release to prod This is simplified, somewhere in between those stages is often automated test, release to staging server, feature toggles, etc. But lets omit those from consideration. Now the proposed way of working would be: feature branch -> merge intro trunk -> review…

> The OP doesn't state not to review code anymore.

Nor am I suggesting he does. I'm saying that merging incorrect code to master might increase velocity if two conditions are fulfilled 1) that people are helped by building on top of the code merged to master and 2) that an incorrect master does NOT create issues that slows down the velocity more than 1) helps.

And that second bit is the case, for example, if the master branch is used to create data (document files, for example) that would be useless or require manual salvaging, if the master branch is broken.

Post reply on HN