Every program has maturation cycle. you don’t just write the final thing. You work your way there.
Early on, a program/module is very fluid, no clear boundaries. Don’t decide program structure apriori, the solution by itself should determine it. Organic evolution.
Clean code practices suggest keeping minimal-sized functions, but this way, tracking of an execution state becomes harder. When we have 100 non-pure functions, each of which could modify global state, it becomes harder to understand program flow. It’s more job structuring program apriori, when it has fluid state - changes a lot. You just often end up doing redundant job this way - organizing a structure which later may be reorganized again. Factoring should be done with program maturation.
If a lot of operations are supposed to happen in a sequental fashion, their code should follow sequentially.
We don’t fear big-sized functions early-on. When it’s time, we factor our code in the following manner:
The approach of maturation cycle is applicable to many fields in my life. Fast start and gradual structuring and organization. I write my notes the same way - the big notes are decomposed into small ones as i continue research. I stopped doing structuring in advance - it hurt so many projects of mine, so it cost me complete rewrite of many unecessary complicated things.
In the cruel business world we often even don’t have enough time and resources to afford any premature organization. Best method that works with our philosophy - skateboard approach.
Premature abstraction and optimization is the root of all evil things that may happen to our project. These things slow us down, increase resource costs, at some point even push us to close the project. If our plans are simple and straightforward, at the implementation stage our creative minds come with things that’s not yet, or never will be, required.