What even does "keep it simple" mean. What even is "understandable". Every article about this sort of thing skips past the interesting arguments and assumes that their approach is the simple one, that their aim is simplicity.<p>If you are presented with the option of an abstraction – perhaps a library or framework, perhaps a service or API – is it "simpler" to use it or to not?<p>If you don't use it, and you build the alternative, you know more about how the system works as a whole, and therefore arguably it's simpler. But complexity is still introduced, and in some cases the abstraction layers still need to be built (but maybe not all of them).<p>If you do use it, you can consider the system to be simpler because you hide the complexity, and on the happy-path of usage that may be true, but the complexity still exists and you don't understand it because it's hidden. Arguably it's simpler, but it's easy to point to how it's more complex.<p>I've met engineers who strongly prioritise one or the other of these sorts, and to them that way is <i>obviously</i> simpler, but the problem is that both approaches are <i>obviously</i> simpler when you look at them in a certain way, you have to get past the obvious to realise that there are trade-offs.