• MajinBlayze@lemmy.world
    link
    fedilink
    English
    arrow-up
    19
    ·
    1 year ago

    More often than not this is “it seems like there are problems with how it’s implemented but I can’t think of them now” but sometimes it definitely is “that’s not the way I would have done it and therefore wrong”

    All that said, I used to work with a guy that would find a reason to fail every code review. It became common for people to add intentional easy mistakes so that the lead could feel like he was contributing.

    • Hazzard@lemm.ee
      link
      fedilink
      English
      arrow-up
      10
      ·
      1 year ago

      Oof, so counterproductive. I’m a hard reviewer, always try to hold others to the standard of code I’d like to work in, and be held to myself, but every once in a while I see a PR that’s just… no changes required.

      I love just hitting accept without making any feedback, it means my coworker valued my feedback and actually internalized it. Trying to laser in and nitpick something unnecessary would be a waste of all our time.

    • ElectricMoose@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      not the way I would have done it

      It could be a legitimate criticism. Sticking to a codebase style and to the language idioms improves clarity and thus maintainability. But then, that means the way to do it should already be clear.

    • Jentu@lemmy.film
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      I’m not a programmer, but I work in a creative field. I routinely have to create red herrings so the producer, creative director, and clients can feel like they contributed by suggesting to remove the thing I intentionally put in there just so they can suggest its removal. It’s exhausting trying to manage everyone’s egos.