[olau]

My personal yardstick is that code should be as easy to understand and take over as possible.

Imagine a future co-worker coming in to fix a bug in your code - that person should ideally be able to say, aha, write a fix, and afterwards nobody can tell you didn't do it yourself.

If an abstraction makes things easier to understand, do it. If it doesn't, don't. Sometimes an extra test can make something easier to understand or modify, or handling more edge cases can make it the code more robust against future uses. But it's always a trade-off: less code is plainly easier to understand.

With that yardstick, lots of hyped tech just isn't good enough, advice given goes plainly against understandability or APIs that may look nice on paper result in hard-to-understand code full of accidental complexity. This applies to a lot of software method thinking too - does it result in me understanding the use cases better or in more understandable code? If not, don't waste time doing it.

By the way, writing code that's easy to understand and APIs that result in usage of said APIs being easy to understand is really hard. I spend a fair deal of my time rewriting code that I'm not comfortable with because it's too hard to understand. If you practice that, I think you might end up as an excellent programmer. Understandability extends to user interfaces and system design - a beautiful program that requires its users to jump through hoops to get everyday tasks done is an abomination in my book.