• souperk@reddthat.com
    link
    fedilink
    arrow-up
    64
    arrow-down
    1
    ·
    2 days 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
      29
      ·
      2 days 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
        13
        ·
        2 days 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
      3
      arrow-down
      1
      ·
      2 days 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?