> “Not needing to care reduces the cognitive load on me, which means it reduces complexity. Since our propensity to make mistakes increases very quickly with co

> “Not needing to care reduces the cognitive load on me, which means it reduces complexity. Since our propensity to make mistakes increases very quickly with complexity, keeping it low is key to success.” I actually have come to disagree strongly with this beyond a very, very tiny amount of basic attribute encapsulation, over my career. Inevitably, 99% of your time becomes dealing with the headache of how the abstraction hides the underlying details at the next reductive step down the chain. You quickly realize that the “win” you get from being able to express a program more concisely in terms of a layer of intermediate abstractions is pretty meaningless, because the number one thing you and all future code readers will need is immediate visibility into how properties of the implementation result in certain resource usage, running time, etc. The number one day to day activity will be performing surgery at some layer below the top line abstraction, to such a degree that the abstraction is nothing more than a nuisance. This is also one reason why a functional style tends to work so well. You separate data encapsulation (in dumb no-method, no-inheritance record types) from instruction encapsulation (just functions), and the abstraction does not have much effect on visibility of the primitives it relies on from the next lower reductive layer of components.