You must log in or # to comment.
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.
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.
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.
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.
