• souperk@reddthat.com
    link
    fedilink
    arrow-up
    98
    arrow-down
    1
    ·
    4 months ago

    I am definitely guilt for that, but I find this approach really productive. We use small bug fixes as an opportunity to improve the code quality. Bigger PRs often introduce new features and take a lot of time, you know the other person is tired and needs to move on, so we focus on the bigger picture, requesting changes only if there is a bug or an important structural issue.

    • NocturnalMorning@lemmy.world
      link
      fedilink
      arrow-up
      47
      ·
      4 months ago

      I always try to review the code anyway. There’s no guarantee that what they wrote is doing what you want it to do. Sometimes I find the person was told to do something and didn’t realize it actually needs to do Y and not just X, or visa versa.

      • ScampiLover@lemmy.world
        link
        fedilink
        arrow-up
        20
        ·
        4 months ago

        I like to shoot for the middle ground: skim for key functions and check those, run code locally to see if it does roughly what I think it should do and if it does merge it into dev and see what breaks.

        Small PRs get nitpicked to death since they’re almost certainly around more important code

    • breakingcups@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      2
      ·
      4 months ago

      So you’re always behind, patching up small bits of code that don’t comply with your guidelines, while letting big changes with, by deduction, worse code quality through?

      • souperk@reddthat.com
        link
        fedilink
        arrow-up
        3
        ·
        4 months ago

        Not really, we are a small team and we generally trust each other. Sure there are things that could have been better, but it’s not bad either.