2021-02-03, 07:37, Wednesday
So I happen to be a morning person. Which means I usually habe to grind my coffee the day before, because the grinder is loud and wakes up the entire family. This is why I have to resort to tea for today, sadly.
It is very important to differentiate solving a problem from creating a product, or a framework, if you will. When there is a single problem (or a set of similar problems) that require a one-time solution, one can get by using spaghetty code and non-optinal solutions without getting into much trouble.
If the code is to be maintained and expanded, then you are writing a product. Now you shouldn't do spaghetti code or omit documenting. This is not about just you anymore, so minimize your succesors' suffering by putting extra effort into cleaning your code.
This seems obvious but is important to keep in mind. I found myself overoptimizing a peice of code required for one-time use.
@FailForward
Thank you for you advice! It has already proven to be helpful: this morning I had to rewrite the code I referred to in my last post pretty much entirely. Changed variable names and sorted some spaghettiness that accumulated, now it's easier to debug.
+bonifartius 𒂼𒄄
@academicalnerd keep in mind that bad code quality increases the probability for bugs which may lead to invalid results due to opaque logic errors.
@academicalnerd
## Dev velocity advice: raise your standards for one-off scripts just slightly and lower those for production-level code
Overoptimizing a one-off script: optimising for performance, elegance, maintainability, standards-compliance, etc. is most of the time indeed a waste of your time in this case. Optimising for **_legibility_** is never a waste of time. Reason is that typically (and you can never predict) if something works well, you will eventually get back to it. You don't want to waste time of your future self. Be nice to that person, it pays off.
Why exactly do you want to stop overoptimising? Because it slows and bogs you down. It's primarily about devel velocity. The goal in your situation thus could be to use the _cheapest_ lessons and personal standards from writing production-level code and carefully apply them to your one-off code. Over time you raise the level of your one-off code quality significantly, while not sacrificing your devel velocity. What we speak about in reality is typically this: short, to-the-point and strategically placed comments, simple readable structures instead of smart and fancy, stuff which works together shall be placed close together, etc. Over time you might realise that actually this is most of the time enough for production-level code too.
Unsolicited advice from far beyond the hill you are walking up to. I like these daily notes from your journey. Keep going!