|
|
|
|
|
by jaredklewis
321 days ago
|
|
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. |
|
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.