> Now I introduce abstractions only if I decide that the future reader could confidently modify the code without looking at the implementations Going full no t

> Now I introduce abstractions only if I decide that the future reader could confidently modify the code without looking at the implementations Going full no true scotsman, but is it really an abstraction if that property does not hold true? Isn't the author essentially arguing against leaky abstractions, which should self-evidently be a bad idea? The problem of course is that developers do not always have the prescience to predict if an abstraction will be leaky or not.