• Fades@lemmy.world
    link
    fedilink
    arrow-up
    6
    arrow-down
    1
    ·
    edit-2
    1 month ago

    It’s so fucking goddamn sad how rare this is. Personally I review changes when I push commits and review all changes personally before publishing the PR and requesting reviews. I’m a senior dev so I guess it’s just something that comes with time (if you care about the code you produce)

    I swear to fucking god every PR review I do for younger devs and contractors we have to use (guess what country they’re from), I swear they don’t even look at their own fucking code once they’ve written it, let alone perform any sort of critical analysis. thoughts about any missed use-cases/optimization/future application and evolution? Nah!! That’s what the PR is for right? 🤬

    As you said even just a quick once over make a big difference and somehow it’s not even close to common.

    Damn I need to quit

    • NotMyOldRedditName@lemmy.world
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 month ago

      This is my typical experience as well, too many people don’t do a code review of their own PR first.

      When I was a junior, I had this coworker who did all my reviews. I was doing my absolute best and wanted to show that I was learning, so I would review all my work before submitting it and think, how would he review and respond to this code.

      That just stuck with me and it’s my normal practice now.

      I eventually learned that’s not as normal as I thought. I also tend to give better code reviews than others.

      Edit: the other thing I do is check in with who will be reviewing my code well before I submit anything someone might think is weird and have a discussion about it before the reveiw. If it’s weird, there might be a better way unless were stuck due to technical debt or something, and doing that early vs at the end usually saves time.