The question then becomes: when do you break out code or not? Unfortunately (or fortunately if the art and craft or programming fascinates you), the answer is n

The question then becomes: when do you break out code or not? Unfortunately (or fortunately if the art and craft or programming fascinates you), the answer is not easy. It seems to have to do with avoiding over-fitting or under-fitting the domain and purpose, to do with getting the best fit in a Bayesian Occam's Razor sense. Minimizing unnecessary code but also doing "Dependency Length Minimization" of the parse tree of your program so that it's maximally understandable and the abstractions increase the potential of your program to correctly interpolate into unknown future use cases. I reflect on some of these points here: https://benoitessiambre.com/abstract.html https://benoitessiambre.com/abstract.html . It's about entropy minimization, calibration of uncertainty. It's about evolving your code so that it tends toward an optimal causal graph of your domain so that your abstractions can more easily answer "what if" questions correctly. These things are all related.