Why your team doesn't need to use pull requests • Hacker News Board

Re: Why your team doesn't need to use pull requests

#71

Post by alkonaut » Mon, May 22, 2023, 9:31 PM UTC

A first requirement for direct-to-main development is that you can be reasonably sure your code will not break the CI build otherwise you'll ensure perpetually broken builds and a process many times slower than PR:s.

Because that’s what PRs are mostly: validation that they won’t break the build on main. Reviews aren’t strictly necessary but compiling is.

In some small project you might be able to run compile/test as part of a commit hook but for a situation where builds might take several hours or the developer can’t test all platforms that CI will, then it’s only possible to keep a green main by validation. In that scenario reviews wouldn’t be the limiting factor either.

Re: Why your team doesn't need to use pull requests

#72

Post by JenrHywy » Mon, May 22, 2023, 11:31 PM UTC

twic wrote: post #58

JenrHywy wrote: post #49

Earlier quoted context omitted.

I've done pairing in the past, and as much as it was fun and felt productive, it was completely exhausting. I don't know how people do it day-in-day-out. I always wonder if the pairing advocates and extroverts, and if that's why it hasn't really caught on in a field with a high percentage of introverts.

It is very tiring. When i started doing it, i was amazed how tired i felt at the end of a 9 to 5 workday. But i got used to it, and it wasn't long before it was perfectly comfortable. I think there's some sort of mental muscle you exercise by pairing, and it takes a while to develop the endurance it needs. I do wish pairing advocates talked about this. It feels mildly fraudulent not to. I'm not sure introversion vs e…

> I'm not sure introversion vs extraversion is relevant. Firstly, i'm not sure they're even real things; they show up in a lot of snake oil psychology (Jung, Myers-Briggs)

Calling Jung snake-oil psych is a bit of a hot take!

Outside of that, Introversion/Extroversion is part of the Big 5 personality traits which I understand to be widely accepted and (unlike a lot of psych) replicated multiple times.

In any case, at the end of a day of pairing I find myself exhausted and have basically no desire to communicate with anyone for the rest of the day. Maybe that's something I'd get used to eventually, though I'm doubtful.

Re: Why your team doesn't need to use pull requests

#73

Post by lodovic » Tue, May 23, 2023, 9:39 AM UTC

SideburnsOfDoom wrote: post #68

lodovic wrote: post #50

Earlier quoted context omitted.

Unless you work in a very complex technical domain with high profit margins. A bug in production can literally cost us billions (apart from potential reputation damage), the system is highly complex, so having 2 reviewers isn't a luxury for us but a necessity.

You could make the same argument about automation not manual process. e.g. "A bug in production can literally cost us billions (apart from potential reputation damage), the system is highly complex, so having robust test suites, automated monitoring and rollback isn't a luxury for us but a necessity." IMHO, automation wins every time. That is, while there is value in "stop the pipeline versions of code review", we va…

That is a perfectly acceptable alternative, but to me it feels it would put a lot of trust in automation and lower affinity with the code as it's not continuously inspected. It depends on the size and duration of the project I guess.

Re: Why your team doesn't need to use pull requests

#74

Post by SideburnsOfDoom » Tue, May 23, 2023, 10:46 AM UTC

lodovic wrote: post #73

SideburnsOfDoom wrote: post #68

Earlier quoted context omitted.

You could make the same argument about automation not manual process. e.g. "A bug in production can literally cost us billions (apart from potential reputation damage), the system is highly complex, so having robust test suites, automated monitoring and rollback isn't a luxury for us but a necessity." IMHO, automation wins every time. That is, while there is value in "stop the pipeline versions of code review", we va…

That is a perfectly acceptable alternative, but to me it feels it would put a lot of trust in automation and lower affinity with the code as it's not continuously inspected. It depends on the size and duration of the project I guess.

> code as is not continuously inspected.

That's not what I said, and is not my experience.

Re: Why your team doesn't need to use pull requests

#75

Post by SideburnsOfDoom » Tue, May 23, 2023, 10:49 AM UTC

ruh-roh wrote: post #70

SideburnsOfDoom wrote: post #29

Earlier quoted context omitted.

> Does a change being accepted into master equal it becoming live in production at your company? Where I am, and at other good companies that I know of, "a change being accepted into main" equals processes being automatically started, that progress it through further environments and test suites, that if they all go well, result in "it becoming live in production" with no further human intervention. So you oversimpli…

I joined a company last year that has a handful of legacy products, and we successfully moved one of them to a CD model a few months ago. It's hilarious to sit back and watch every other team have the same monthly loop of big change -> lengthy test cycle -> "go-live" meeting -> fixes/big change -> more testing... etc. Loads of stress and finger-pointing. Hardly ever hear a peep from the CD team. Sure, it's not all ra…

Congratulations. But it might be time to "make a peep" internally to other teams about "how we successfully moved to a CD model and what it gave us, and how you can do it too".

Mainly for your colleague's stress levels, and secondarily for the business's success.

Re: Why your team doesn't need to use pull requests

#76

Post by nelgaard » Tue, May 23, 2023, 12:29 PM UTC

lodovic wrote: post #4

I strongly disagree with this article. I wouldn't trust myself or my my coworkers to produce perfect code every time. We have 2 reviewers mandatory for each PR and using pull requests is a perfectly acceptable way to ensure quality - every line of code has to be vetted by at least 3 developers (it has to pass the CI/CD pipeline checks as well). If you produce high end software with complex workflows and/or calculatio…

But is it the most efficient way to ensure that level of quality?

PR-s influence the same code, so it is not enough to review PR-s individually anyway. Maybe a weekly or monthly release would be a better unit for evaluation.

We have all kind of ways of producing diffs between branches, releases, tags, timestamps, etc? Why would PR diffs be the most efficient unit to review?

Often PR-s are just a silly way to communicate between team members instead of just talking to each other. I.e., you sit in the same office and create and reject PR-s, when you could just say to you colleague: "if you do not like the name of that variable, feel free to change the name".

The main problem with the PR system is that changes to the code is not immediately committed to the branches that developers work on, so it limits cooperation between developers. You can still review commits to dev branches and if problems are found, you can fix them or in most cases undo them.