I watched the Structure and Interpretation of Computer Programs lecture recordings, and one lesson I got out of them very strongly: create a toolkit to solve pr

I watched the Structure and Interpretation of Computer Programs lecture recordings, and one lesson I got out of them very strongly: create a toolkit to solve problems in the space of your initial conception of the problem. Your initial instinct of what the problem is, is typically wrong, and the demands on your program typically evolve anyway. I hesitate to use the phrase "domain specific language" because it brings baggage, but that's the platonic ideal of a toolkit. The core skill of building toolkits is picking flexible ways to decompose problems. Top-down planning and decomposition has a way of biting you in the ass at the worst times, when you're almost done except for one corner case. Bottom-up construction tends to be more flexible if dirtier.