There’s a quote that I’m having trouble sourcing, but it’s basically:
Code is for humans to read, and only incidentally for computers to execute.
I think a lot of things are like that, especially when it comes to defining and organizing work. It’s less about making the perfect requirements document and more about getting everyone to think about a shared goal in a similar way.
Specifics are great because they make for solid landmarks. But abstract language is essential too, because it clues you into how you ought to navigate the terrain in between those landmarks.
And there is always space in between the specifics. If you managed to nail down every last detail in your spec, congratulations on your new hand-compiled programming language.
This is why I like strongly opinionated frameworks! People get hung up on whether they agree with the opinions themselves, which is valid, but I think kinda misses the point. The great strength of opinionated frameworks is the speed with which you can get “everyone to think about a shared goal in a similar way”, to use your phrasing. They do have their problems of course and if you ask me in 5 years, maybe I feel the opposite way about it.
I also tend to like opinionated frameworks. On top of easing the onboarding process, they can also afford to have more detailed docs/support/stability because they don’t have to account for there being a million ways to do even a basic thing.
I’m sympathetic, in theory, to the downsides noted by Rich Hickey in Simple Made Easy and Uncle Bob in Architecture The Lost Years… but IRL, I can’t say I’ve ever seen a project successfully lean into those principles at any significant scale. So maybe more of an academic appreciation there.
There’s a quote that I’m having trouble sourcing, but it’s basically:
Code is for humans to read, and only incidentally for computers to execute.
I think a lot of things are like that, especially when it comes to defining and organizing work. It’s less about making the perfect requirements document and more about getting everyone to think about a shared goal in a similar way.
Specifics are great because they make for solid landmarks. But abstract language is essential too, because it clues you into how you ought to navigate the terrain in between those landmarks.
And there is always space in between the specifics. If you managed to nail down every last detail in your spec, congratulations on your new hand-compiled programming language.
I just saw it quoted the other day here https://youtu.be/MWsk1h8pv2Q?t=248 but it’s unattributed so I did a search: Abelson & Sussman, “Structure and Interpretation of Computer Programs” https://en.wikiquote.org/wiki/Programming_languages
This is why I like strongly opinionated frameworks! People get hung up on whether they agree with the opinions themselves, which is valid, but I think kinda misses the point. The great strength of opinionated frameworks is the speed with which you can get “everyone to think about a shared goal in a similar way”, to use your phrasing. They do have their problems of course and if you ask me in 5 years, maybe I feel the opposite way about it.
I also tend to like opinionated frameworks. On top of easing the onboarding process, they can also afford to have more detailed docs/support/stability because they don’t have to account for there being a million ways to do even a basic thing.
I’m sympathetic, in theory, to the downsides noted by Rich Hickey in Simple Made Easy and Uncle Bob in Architecture The Lost Years… but IRL, I can’t say I’ve ever seen a project successfully lean into those principles at any significant scale. So maybe more of an academic appreciation there.