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

Why your team doesn't need to use pull requests

infrastructure-as-code.com

Post reply on HN
Print view View original

51–60 of 76 posts

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

#51

Post by SideburnsOfDoom »

JenrHywy wrote: post #49
MrGilbert wrote: post #37

Earlier quoted context omitted.

> Pair programming.. sure.. but PP is so resource intensive and often it's better to have people focus by themselves imho. Wholeheartedly disagree on the last part. Yes, Pair programming is expensive, but the knowledge transfer is invaluable. I would encourage people to work together on the same problem.

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.

Pairing is exhausting because it's intense.

Even a couple of hours of pairing per day is a huge team productivity boost though. Don't do it "all day every day".

It's OK to say "I'll go away for the afternoon to flesh out these tests as we have discussed".

I'll say that it's less about if the PR exists or not, but by the time it's raised it should be fine to merge it pretty much as soon as it's green, because people are on the same page before the code was even written.

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

#52

Post by xmcqdpt2 »

edaemon wrote: post #28

Hm, the section on using CI rather than pull requests seems odd. PRs can be part of CI. You can set up your pipeline to build and test the result of a PR; that is, you are testing each change as if you had pushed it to the project's mainline, but there's no potential for you to break the mainline branch in a way that hinders your team. This is very nearly touched on in the "pipeline approvals" section: "...you place…

> Hm, the section on using CI rather than pull requests seems odd. PRs can be part of CI. You can set up your pipeline to build and test the result of a PR; that is, you are testing each change as if you had pushed it to the project's mainline, but there's no potential for you to break the mainline branch in a way that hinders your team.

That doesn't actually stop you from breaking mainline though, just make it significantly less likely.

Say you are developing a class Foo, and I'm adding new code that uses Foo. You decide to refactor Foo to Bar. We won't get a conflict because I'm adding new code and not touching the Foo class.

In that case we both have pull requests that build fine but that once merged, won't compile. Running pipelines on each PR reduces the breakage but it can't eliminate it, unless you only allow one PR to build then merge at a time.

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

#53

Post by twic »

masklinn wrote: post #25
kstenerud wrote: post #6

> Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem. No, it's like having an editor proofread your article before you submit it. It's a second pair of eyes to make sure you haven't missed something or made a change that will subtly break things, or just misundersto…

Also as far as I can tell OP’s recommendation is to break the mainline, then tell everyone it’s broken. > Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and integrate it into the mainline IME that’s a perfect recipe for getting a mainline which never passes tests in any organisation of a non-trivial size, as soon as broken code has been pushed “giving a fuck” goes…

No. You and those replying to you have completely misunderstood what the author wrote. My emphasis and a clarifying adverb:

> As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and [then] integrate it into the mainline with everyone else’s current work.

You get your local copy into a healthy state - build passing, tidied up, refactored - and then you push it upstream. The idea is precisely that you only push healthy code, and so never break mainline.

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

#55

Post by twic »

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…

The author does not say that you should not review code. There is a whole section of the post about how to review code.

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

#56

Post by masklinn »

twic wrote: post #53
masklinn wrote: post #25

Earlier quoted context omitted.

Also as far as I can tell OP’s recommendation is to break the mainline, then tell everyone it’s broken. > Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and integrate it into the mainline IME that’s a perfect recipe for getting a mainline which never passes tests in any organisation of a non-trivial size, as soon as broken code has been pushed “giving a fuck” goes…

No. You and those replying to you have completely misunderstood what the author wrote. My emphasis and a clarifying adverb: > As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and [then] integrate it into the mainline with everyone else’s current work.…

No, we understand perfectly well what the author wrote, but we’ve also worked with actual breathing humans rather than just spherical cows in vacuum, so we understand what will inevitably happen.

This is about as realistic as telling devs not to push bugs. As soon as it gets in the way or there’s a boss breathing down the dev’s neck, anything which is not enforced is jettisoned.

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

#57

Post by majewsky »

twic wrote: post #53
masklinn wrote: post #25

Earlier quoted context omitted.

Also as far as I can tell OP’s recommendation is to break the mainline, then tell everyone it’s broken. > Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and integrate it into the mainline IME that’s a perfect recipe for getting a mainline which never passes tests in any organisation of a non-trivial size, as soon as broken code has been pushed “giving a fuck” goes…

No. You and those replying to you have completely misunderstood what the author wrote. My emphasis and a clarifying adverb: > As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and [then] integrate it into the mainline with everyone else’s current work.…

Yes, and this is how things were supposed to go before PRs. Whenever PR requirements are added, it's always because the described process does not work in reality and mainline ends up filling with crap as developers under pressure try to rush their prio-1 features out the door.

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

#58

Post by twic »

JenrHywy wrote: post #49
MrGilbert wrote: post #37

Earlier quoted context omitted.

> Pair programming.. sure.. but PP is so resource intensive and often it's better to have people focus by themselves imho. Wholeheartedly disagree on the last part. Yes, Pair programming is expensive, but the knowledge transfer is invaluable. I would encourage people to work together on the same problem.

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 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), but i don't know to what extent they label a real axis of variation. But if extraversion means "the state of primarily obtaining gratification from outside oneself", then an extravert ought to hate pairing, because it's the same as programming solo, but with someone constantly pointing out what you've done wrong. The conversation you have during pairing is very, very different to a normal social conversation, because it's so focused on the work in hand.

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

#59

Post by kstenerud »

twic wrote: post #53
masklinn wrote: post #25

Earlier quoted context omitted.

Also as far as I can tell OP’s recommendation is to break the mainline, then tell everyone it’s broken. > Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and integrate it into the mainline IME that’s a perfect recipe for getting a mainline which never passes tests in any organisation of a non-trivial size, as soon as broken code has been pushed “giving a fuck” goes…

No. You and those replying to you have completely misunderstood what the author wrote. My emphasis and a clarifying adverb: > As a team member, you don’t wait until you have finished a feature or story to integrate your code to the mainline. Instead, you frequently - at least once a day - put your code into a healthy state that passes tests and [then] integrate it into the mainline with everyone else’s current work.…

So basically everything that one would normally finish with a PR, but without a PR.

In my daily work, I never reject a PR for failing tests (the CI system disallows merging until all tests, lint, warnings, danger, style have passed). So whenever I find a problem in a PR, it's due to something that is not detected (or possibly not even detectable) by the automated checks. By dropping the PR requirement, you lose that added check.

FWIW in a team of only experienced (>10 years) devs, I find problems in approximately 20% of the PRs I review (granted our codebase has numerous subtleties due to the esoteric nature of our domain). We've also had problems that even the reviewer missed; problems that broke mainline and made merging impossible until the issues were fixed.

It's fine to say "we'll just accept the added risk", but you really need to do it with eyes open. I personally won't accept such risks unless I absolutely have to (i.e. can't find a reviewer and the customer is breathing down our necks). That's one thing that 25+ years in the industry has taught me.

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

#60

Post by twic »

jacknews wrote: post #7

Is the author suggesting every commit goes into the main branch, and into production? That seems ludicrous. The trick with merge requests is to keep them as small as possible while being something that can potentially be deployed into production, ie some kind of fix or feature, not just dead code.

This is called "continuous deployment", and it was all the rage ten years ago. I'm surprised the idea seems unfamiliar now, but that's how this industry works, i suppose!
Post reply on HN