Recently, I had a conversation with a junior developer on my team. Let’s call him Alan. We were talking about a new notification feature that was going to be used to send reminder e-mails to potentially thousands of people if they had forgotten to enter certain data in the last month or so. Alan was confident that the code he’d written was correct. “I’ve tested it well.”, he said…
  • bungle_in_the_jungle@lemmy.world
    27·
    5 months ago

    Something I find helpful is to PR review my own code before I create the actual PR. It’s surprising how giving it a once over in a different setting to the comfort zone of your code editor can save you a bit of unnecessary back and forth.

    • magic_lobster_party@kbin.run
      10·
      5 months ago

      I do that all the time. Sometimes I even realize I missed an even more obvious solution to the problem or how to better communicate the intent of the code.

    • groucho@lemmy.sdf.orgEnglish
      8·
      5 months ago

      Yep. This is the way. Also, you’d be surprised how many devs don’t run through their own QA steps before asking other people to verify.

    • some_guy@lemmy.sdf.org
      5·
      5 months ago

      I like to take any text and copy / paste it into a different editor. Inevitably, this changes the layout because of different font settings or window size or whatever else. Reading it in a slightly altered layout helps me catch a lot of tiny errors that my eyes otherwise glide past.

    • Fades@lemmy.world
      61·
      5 months 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
        4·
        5 months 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.

    • stuckgum@lemmy.ml
      14·
      5 months ago

      I wouldn’t do that, too much tunnel vision and biases. I just skim through and make sure everything makes sense. Especially naming and comments.

      • Kissaki@programming.devEnglish
        8·
        5 months ago

        I wouldn’t do that, too much tunnel vision and biases.

        Absolutely not. Self-reviews are very productive. I can confirm this from my own work and my colleagues, who also find it so.

        You’re of course free to vary the degree and depth of self-review, but tunnel vision and bias is definitely not overbearing and diminishing in those situations for us.

        Someone else will of course see more, what you may not see due to tunnel vision. But that’s besides the point.

        • stuckgum@lemmy.ml
          13·
          5 months ago

          Weird, never heard of anyone doing this. Aren’t your team self reviewing the code while writing it?

          • Rogue@feddit.uk
            8·
            5 months ago

            When you finish the final sentence of an essay or a report do you just submit it straight away? You don’t read it through?

          • Kissaki@programming.devEnglish
            5·
            5 months ago

            How do you self-review while writing? What do you mean by that?

            I see it as different phases of development, mindset, and focus. You inherently can’t be in multiple at the same time.

            1. Problem space and solution exploration - an iterative and at times experimental process to find and weigh solutions
            2. Cleanup and self-review - document your findings, decision-making, exclusions, and weighing, verify your solution/changeset makes sense and is complete (to intended scope)
            3. Reviews

            It makes no sense to be thorough during experimental and iterative exploration. That’d be wasted effort.

            After finding a solution, and writing it out, a self-review will make you take a systematic, verifying review mindset.

      • icesentry@lemmy.ca
        4·
        5 months ago

        I just skim through and make sure everything makes sense. Especially naming and comments.

        What do you think a self review is?

      • SatouKazuma@ani.social
        1·
        5 months ago

        I think it makes sense, but only after logging out for the day and coming back to it a bit either the next day, or after a weekend in the case of code completion late Thursday or early Friday.