Excellent breakdown of the relevant factors at play.
You Don’t Get To Choose The Problem Factorization
But what if you need to work on a problem you don’t understand anyway?
That creates Spaghetti Towers: vast constructs of ad-hoc bug-fixes and tweaks built on top of bug-fixes and tweaks. Software-gore databases, Kafkaesque-horror bureaucracies, legislation you need a law degree to suffer through, confused mental models; and also, biological systems built by evolution, and neural networks trained by the SGD.
That’s what necessarily, convergently happens every time you plunge into a domain you’re unfamiliar with. You constantly have to tweak your system momentarily, to address new minor problems you run into, which reflects new bits of the domain structure you’ve learned.
Much like biology, the end result initially looks like an incomprehensible arbitrary mess, to anyone not intimately familiar with it. Much like biology, it’s not actually a mess. Inasmuch as the spaghetti tower actually performs well in the domain it’s deployed in, it necessarily comes to reflect that domain’s structure within itself. So if you look at it through the right lens – like those of a programmer who’s intimately familiar with their own nightmarish database – you’d actually be able to see that structure and efficiently navigate it.
Which suggests a way to ameliorate this problem: periodic refactoring. Every N time-steps, set some time aside for re-evaluating the construct you’ve created in the context of your current understanding of the domain, and re-factorize it along the lines that make sense to you now.
That centrally applies to code, yes, but also to your real-life projects, and your literal mental ontologies/models. Always make sure to simplify and distill them. Hunt down snippets of redundant code and unify them into one function.
I. e.: When working on a problem you don’t understand, make sure to iterate on the problem factorization.
Excellent breakdown of the relevant factors at play.
But what if you need to work on a problem you don’t understand anyway?
That creates Spaghetti Towers: vast constructs of ad-hoc bug-fixes and tweaks built on top of bug-fixes and tweaks. Software-gore databases, Kafkaesque-horror bureaucracies, legislation you need a law degree to suffer through, confused mental models; and also, biological systems built by evolution, and neural networks trained by the SGD.
That’s what necessarily, convergently happens every time you plunge into a domain you’re unfamiliar with. You constantly have to tweak your system momentarily, to address new minor problems you run into, which reflects new bits of the domain structure you’ve learned.
Much like biology, the end result initially looks like an incomprehensible arbitrary mess, to anyone not intimately familiar with it. Much like biology, it’s not actually a mess. Inasmuch as the spaghetti tower actually performs well in the domain it’s deployed in, it necessarily comes to reflect that domain’s structure within itself. So if you look at it through the right lens – like those of a programmer who’s intimately familiar with their own nightmarish database – you’d actually be able to see that structure and efficiently navigate it.
Which suggests a way to ameliorate this problem: periodic refactoring. Every N time-steps, set some time aside for re-evaluating the construct you’ve created in the context of your current understanding of the domain, and re-factorize it along the lines that make sense to you now.
That centrally applies to code, yes, but also to your real-life projects, and your literal mental ontologies/models. Always make sure to simplify and distill them. Hunt down snippets of redundant code and unify them into one function.
I. e.: When working on a problem you don’t understand, make sure to iterate on the problem factorization.