• JackDark@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    4 days ago

    My advice: Practice going over other people’s code with a fine-tooth comb looking for bad architecture, flaws and inefficiencies.

    I agree. Funny story, I wasn’t allowed to do code reviews at my current job for about 2 years because they thought my comb was too fine. Suddenly software quality is something they are really valuing and they’re allowing me to do code reviews again. Funny, that.

    • cecilkorik@lemmy.ca
      link
      fedilink
      English
      arrow-up
      5
      ·
      4 days ago

      Yeah when I first started there was one guy whose code reviews I dreaded, he would nitpick every detail and he would stand by it, he would tell me to do it a completely different way that was 10x more work. It felt like I would never get my stories done because I had drawn “that asshole” in the code review lottery.

      Years later, I came to realize that he was actually the best, he taught me so much about the way I should be thinking of things and structuring things, that have saved so much time and trouble later on, I now specifically reach out to him for a review when I am trying to do something complex because I know he’s going to give me an honest, thorough and useful review. Nobody’s doing anyone any favours in the long run by rubber stamping things, it may help you keep your sprint velocity up, but it’s not going to result in high quality code, and the bad quality code will inevitably bite you.