• vvv@programming.dev
    link
    fedilink
    arrow-up
    17
    arrow-down
    10
    ·
    1 year ago

    Mandatory pull requests + approvals within a team are a waste of everyone’s time.

    • apd@programming.dev
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      Big hot take to me; especially in an organization with a large size and code high standard

    • fusio@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      depends on the company/team culture. are other people gonna have to fix or extend code you wrote? are you the sole engineer working on entire modules? do you hate feedback?

    • TehPers@beehaw.org
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      1 year ago

      You must trust your team’s abilities more than I trust my own. How often does your team merge bugs into main? We use CI primarily for running the full test suite, including integration tests and e2e tests that would be very difficult to run locally due to them using specific credentials to access testing resources.

        • TehPers@beehaw.org
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          I trust my team. I don’t trust my or their ability to write and merge perfect code each time. I’m not sure how we’d fix that problem aside from becoming programming gods.

          • vvv@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            My point is, having PRs desn’t result in perfect code either. They might help sometimes, maybe 10% of the time if I’m being generous, but the rest of the time they are a hindrance. The problems people tend to try and solve with them, validation and indoctrination are better solved with a good CD pipeline, and pairing sessions.

    • uniqueid198x@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      6
      arrow-down
      3
      ·
      1 year ago

      We’v known this for twenty years and had the data ta back it up for ten. Github flow is one of the most damaging things to ever happen to software teams

        • uniqueid198x@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Got asked about this twice so I’m cut/pasting my answer, but happy to discuss further

          Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.

      • fusio@lemmy.world
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        what data? just curios because there are so many ways to do PRs properly… like for everything, if it’s done badly better not do it. does not mean it is inherently bad

        • uniqueid198x@lemmy.dbzer0.com
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Check out the dora reports and the data Nicole Forsgren lays out in her book Accelerate. DORA reborts are free to access. She has found clear links between trunk based (no branching) development and a whole host of positive metrics. There is some suggestion that PRs are not too bad if always done at high quality and within the same day, but its weaker.

    • Sigmatics@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Depends how good you are at what you’re doing. I’d argue that humans err and it saves a bunch of time to catch bugs before debugging in the wild

    • T (they/she)@beehaw.org
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Unless you have people that are known to delivery garbage code. Which is more common than you would imagine, lol.

      • vvv@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        The solution to that is pairing - spending a few hours collaborating with, and teaching this person will get them up to speed much faster than asynchronously nitpicking their code.