Any tips to help a scientist become a better programmer? - eviltoast

Hey there!

I’m a chemical physicist who has been using python (as well as matlab and R) for a lot of different tasks over the last ~10 years, mostly for data analysis but also to automate certain tasks. I am almost completely self-taught, and though I have gotten help and tips from professors throughout the completion of my degrees, I have never really been educated in best practices when it comes to coding.

I have some friends who work as developers but have a similar academic background as I do, and through them I have become painfully aware of how bad my code is. When I write code, it simply needs to do the thing, conventions be damned. I do try to read up on the “right” way to do things, but the holes in my knowledge become pretty apparent pretty quickly.

For example, I have never written a class and I wouldn’t know why or where to start (something to do with the init method, right?). I mostly just write functions and scripts that perform the tasks that I need, plus some work with jupyter notebooks from time to time. I only recently got started with git and uploading my projects to github, just as a way to try to teach myself the workflow.

So, I would like to learn to be better. Can anyone recommend good resources for learning programming, but perhaps that are aimed at people who already know a language? It’d be nice to find a guide that assumes you already know more than a beginner. Any help would be appreciated.

  • boeman@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    8 months ago

    You aren’t wrong… But everything with extended use needs to be maintainable. Making a change in 5 places sucks.

    Plus, that’s what open-closed principle is all about. Instead of adding additional functionality to current working code, you extend and modify.

    • Fal@yiffit.net
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      3
      ·
      8 months ago

      Making a change in 5 places sucks, making it in 2 could be reasonable. If 2 pieces of code are similar but different enough, I’ve seen way too often people try to force them into a common abstraction. That’s more what the article is about.