Intuitively, this feels accurate to me (at least for a certain category of problems—those that are solvable with divide and conquer strategies).
I’ve always viewed most software best-practices (e.g. modularity, loose-coupling, SOLID principles) as techniques for “managing complexity”.
Programming is hard to begin with, and programming large systems is even harder. If the code you’re looking at is thousands of lines of code in a single file with no apparent structure, then it’s extremely hard to reason about. That’s why we have “methods”, a mechanism to mentally tuck away pieces of related functionality and abstract them into just a method name. Then, when that wasn’t enough, we came up with classes, namespaces, projects, microservices ..etc.
Also, I agree that a good amount of learning works this way. I would even point to “teaching” as another example of this. Teaching someone a complex topic often involves deciding what “levels” of understanding are at play, and what subproblems can be abstracted away at each level until the learner masters the current level. This works both when you teach someone in a top-down fashion (you’re doing the division of problems for them and helping them learn the subsolutions, recursively), or a bottom-up fashion (you teach them a particular low-level solution, then name the subproblem you’ve just solved, zoom out, and repeat).
Intuitively, this feels accurate to me (at least for a certain category of problems—those that are solvable with divide and conquer strategies).
I’ve always viewed most software best-practices (e.g. modularity, loose-coupling, SOLID principles) as techniques for “managing complexity”.
Programming is hard to begin with, and programming large systems is even harder. If the code you’re looking at is thousands of lines of code in a single file with no apparent structure, then it’s extremely hard to reason about. That’s why we have “methods”, a mechanism to mentally tuck away pieces of related functionality and abstract them into just a method name. Then, when that wasn’t enough, we came up with classes, namespaces, projects, microservices ..etc.
Also, I agree that a good amount of learning works this way. I would even point to “teaching” as another example of this. Teaching someone a complex topic often involves deciding what “levels” of understanding are at play, and what subproblems can be abstracted away at each level until the learner masters the current level. This works both when you teach someone in a top-down fashion (you’re doing the division of problems for them and helping them learn the subsolutions, recursively), or a bottom-up fashion (you teach them a particular low-level solution, then name the subproblem you’ve just solved, zoom out, and repeat).