• Midas@ymmel.nl
    link
    fedilink
    arrow-up
    18
    ·
    1 year ago

    Really grinds my gears to get a review request for a huge PR with almost no context and no instructions on how to run the code / test data.

    I’ve even had one guy ask for a review who hadn’t even manually tested his own codes happy path. Sure he wrote some unit tests and those ran but once you actually tried using the code in the app all kinds of exceptions and weird situations came up. No idea how people dare do that shit.

    • fiah@discuss.tchncs.de
      link
      fedilink
      arrow-up
      8
      arrow-down
      1
      ·
      1 year ago

      No idea how people dare do that shit

      perhaps we should introduce the PR Wall of Shame for exactly those situations. I mean, obviously you don’t want to strangle productivity by naming and shaming people for every single small mistake, but such egregious violations like not even click testing the happy path should be used as an example of what fucking up looks like

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

        Playing the blame game, especially publicly, is a bad way to encourage psychological safety in a community. See Linus Torvalds for examples (he has recently become a bit softer with his feedback).

        A better option is to make clear expectations of what a good PR looks like. Then if expectations are not met, you can give 1 on 1 feedback. Don’t just blast a noob in public or you can leave emotional scars.

        • fiah@discuss.tchncs.de
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          Don’t just blast a noob in public

          true, but also when someone who’s been around for a while and ought to know better, it can really help to remind them that they’re not above the rules

    • Asifall@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Poor management and time pressure are the answers. It often looks better to push some shit code and then push the fixes later than it does to take twice as long to verify a good change.