Does it really make sense to write code that is say OOP when some standard stuff could have been done, would have been much faster to write, and would have been a similar level of readability because of the shortness of the program?

Personal answer:
I do a lot of scripting for scientific purposes too. For smaller scripts, I simply try to follow general good programming practices (i.e. using version control, practicing self-control with variable names). If I'm just writing something to quickly open or visualize a dataset, I don't bother with OOP.

General Answer:
"It depends." But if you are struggling to figure out when to use a programming concept or paradigms, here are a couple things to think about:

• Scalability: Is the script going to stand alone, or will it eventually be used in a larger program? If so, is the larger programming using OOP? Can the code in your script be easily integrated into the larger program?
• Modularity: In general, your code should be modular. However, OOP breaks code into chunks in a very special way. Does that type of modularity (i.e. breaking up your script into classes) make sense for what you are doing?

I want to know how to "start over" and program cleanly on these smaller, faster projects.

#1: Get familiar with what's out there:
Even though you're "just" scripting (and you really just care about the science component), you should take some time to learn about different programming concepts and paradigms. That way, you can have a better idea of what you should/ should not want to use and when. That may sound a bit daunting. And you may still have the question, "Where do I start/ what do I start looking at?" I try to explain a good starting point in the next two bullet points.

#2: Start fixing what you know is wrong:
Personally, I would start with the things that I know are wrong. Get some version control and start to discipline yourself to get better with those variable names (it is a serious struggle). Fixing what you know is wrong may sound obvious. However, in my experience, I've found that fixing one thing leads me to something else, and so on. Before I know it, I've unveiled 10 different things I was doing wrong and figured out how to fix them or how to implement them in a clean way.

#3: Get a programming partner:
If "starting over" for you doesn't involve taking formal classes, consider teaming up with a developer and asking them to review your code. Even if they don't understand the science part of what you're doing, they might be able to tell you what you could have done to make your code more elegant.

I hope that helps!

Does it really make sense to write code that is say OOP when some standard stuff could have been done, would have been much faster to write, and would have been a similar level of readability because of the shortness of the program?

Personal answer:
I do a lot of scripting for scientific purposes too. For smaller scripts, I simply try to follow general good programming practices (i.e. using version control, practicing self-control with variable names). If I'm just writing something to quickly open or visualize a dataset, I don't bother with OOP.

General Answer:
"It depends." But if you are struggling to figure out when to use a programming concept or paradigms, here are a couple things to think about:

• Scalability: Is the script going to stand alone, or will it eventually be used in a larger program? If so, is the larger programming using OOP? Can the code in your script be easily integrated into the larger program?
• Modularity: In general, your code should be modular. However, OOP breaks code into chunks in a very special way. Does that type of modularity (i.e. breaking up your script into classes) make sense for what you are doing?

I want to know how to "start over" and program cleanly on these smaller, faster projects.

#1: Get familiar with what's out there:
Even though you're "just" scripting (and you really just care about the science component), you should take some time to learn about different programming concepts and paradigms. That way, you can have a better idea of what you should/ should not want to use and when. That may sound a bit daunting. And you may still have the question, "Where do I start/ what do I start looking at?" I try to explain a good starting point in the next two bullet points.

#2: Start fixing what you know is wrong:
Personally, I would start with the things that I know are wrong. Get some version control and start to discipline yourself to get better with those variable names (it is a serious struggle). Fixing what you know is wrong may sound obvious. However, in my experience, I've found that fixing one thing leads me to something else, and so on. Before I know it, I've unveiled 10 different things I was doing wrong and figured out how to fix them or how to implement them in a clean way.

#3: Get a programming partner:
If "starting over" for you doesn't involve taking formal classes, consider teaming up with a developer and asking them to review your code. Even if they don't understand the science part of what you're doing, they might be able to tell you what you could have done to make your code more elegant.

#4: Look for consortiums:
I don't know what scientific area you are in. But depending on what you do in the scientific world, try looking for consortiums, working groups, or conference participants. Then see if there are any standards that they are working on. That may lead you to some coding standards. For example, I do a lot of geospatial work. Looking at conference papers and working groups led me to the Open Geospatial Consortium. One of the things they do is work on standards for geospatial development.

I hope that helps!