Over time I’ve come to appreciate boilerplate more.
Early in my career I really appreciated very DRY code with minimal repetition. However over time I’ve noticed that such code tends to introduce more abstractions as opposed to more verbose code which can often rely on fewer abstractions. I think this is good because I think we also have a sort of “abstraction budget” we have to stay within or our brains, metaphorically, stop reading from memory and need to start reading from disk (consulting docs, jumping to function definitions, etc…)
I feel the ideal code base would rely on a small number of powerful abstractions.
In practice I think this usually means relying mostly on the abstractions built into the language, standard library, and framework used and then maybe sprinkling in a couple of app/domain specific abstractions or powerful libraries that being their own abstraction.
So in my experience reducing boilerplate can often make the code more difficult to understand.
It’s not really an abstraction budget, it’s an “unfamiliar abstraction” budget. You only pay cognitive load for an abstraction when you haven’t yet internalized the abstraction. Otherwise progress would have become impossible long ago.
There’s a huge pile of abstractions in that codebase that you have internalized to the point of invisibility — machine instructions, virtual memory, ASCII, sequential execution, named variables, garbage collection, network streams…literally thousands of these abstractions had to be invented and become second nature to you so these other abstractions that currently aren’t as familiar could be based on them.
A good abstraction gives a return on investment of effort internalizing it. There’s no limit on how many good abstractions you should have.
I think we agree, just I would stipulate that I have to see a an abstraction a lot to internalize it (internalize is a great word for this btw).
Like way more than the rule of 3. Even a dozen uses (if it’s only going to be local to just that particular project) is not enough for me.
Edit: and maybe this just says more about the kinda of languages I use at work, but I feel the conventional, widely understood, idiomatic way to do lots of things is often heavy on boilerplate. If these languages were rewritten from the ground up I imagine with hindsight the core languages and standard libraries would look pretty different and be more ergonomic.
Early in my career I really appreciated very DRY code with minimal repetition. However over time I’ve noticed that such code tends to introduce more abstractions as opposed to more verbose code which can often rely on fewer abstractions. I think this is good because I think we also have a sort of “abstraction budget” we have to stay within or our brains, metaphorically, stop reading from memory and need to start reading from disk (consulting docs, jumping to function definitions, etc…)
I feel the ideal code base would rely on a small number of powerful abstractions.
In practice I think this usually means relying mostly on the abstractions built into the language, standard library, and framework used and then maybe sprinkling in a couple of app/domain specific abstractions or powerful libraries that being their own abstraction.
So in my experience reducing boilerplate can often make the code more difficult to understand.