• Midas ( midas@ymmel.nl ) 
    link
    fedilink
    arrow-up
    14
    ·
    3 years 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 ( fiah@discuss.tchncs.de ) 
      link
      fedilink
      arrow-up
      7
      ·
      3 years 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

      • 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 ( fiah@discuss.tchncs.de ) 
          link
          fedilink
          arrow-up
          2
          ·
          3 years 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

  • dudinax ( dudinax@programming.dev ) 
    link
    fedilink
    English
    arrow-up
    12
    ·
    3 years ago

    True, but the 10 line change can me merged two weeks from now and it won’t make any difference. If you let the 500 line merge languish for two days you’ll have screwed up the work of three other programmers.

  • I know this implies that the reviewer didn’t care to read the bigger PR, but I think this might actually be legit. If your PR is only 10 lines long, then chances are those lines are very dense, or intricate in some other way. However, if you submit 500 lines, then it’s probably mostly boilerplate code with trivial adaptions.

    No-one in their right mind would submit 500 lines of substantial code.

    • nul ( nul@programming.dev ) 
      link
      fedilink
      arrow-up
      7
      ·
      3 years ago

      You’d be surprised. Especially if the testing environment is not readily available or if automated tests are not functional and comprehensive, large code changes can be the norm. A developer may habitually hang onto their code until a big chunk is complete, at which point it will take heaps of debugging to uncover where the errors are. This is why we need IaC to quickly create testing environments that closely mirror prod, and trunk-based development to ensure code changes are small and issues are caught as early as possible.

    • kabat ( kabat@programming.dev ) 
      link
      fedilink
      arrow-up
      5
      ·
      3 years ago

      Has no one here ever worked on a new project or even a new feature in a decently sized codebase? Working exclusively in maintenance / minor change mode has to be exhausting.

      • Depends on what you classify as “minor change”. When I took up my first professional project, I found a plethora of little things to improve which would make users happy. That was very satisfying.

        On the other hand, writing yet another module that displays a list of Foos, lets the user create a Foo, show the details of Foo, update it, and delete a Foo, becomes dull quickly, despite being a “new feature”.

      • I have worked on non-trivial (aka took 10-12 people over a year to even deliver an alpha) greenfield projects, where I literally made the first check-in into the repo.

        The only 500+ line PRs I raised was auto generated boilerplate code, or renaming something.

        I don’t understand the optimism of devs who spend weeks writing code without bothering to test anything they’ve written. Unless you’re writing utterly trivial BS, how does one have this level of confidence in their code? And if you did bother to stop and test, why on god’s green earth would you not raise a PR? Why wait till you have thousands of lines of code before asking for feedback?

  • Astiolo ( Astiolo@lemmy.fmhy.ml ) 
    link
    fedilink
    arrow-up
    2
    ·
    3 years ago

    This can be called the bike shed effect or Law of Triviality. It’s not just programming where a simple digestible idea will be contested because it’s easy to poke holes, while something more complicated and more consequential is much harder, so it gets little to no resistance.

  • Y’all need to get yourselves some PR review automation in place. Stop wasting time on trivial reviews and requesting changes for common problems so that when you ping a colleague for a code review, they know it’s important rather than a simple request for a thumbs up.