Any code should be simple and easy to read / understand.

I just reworked an old stored SQL proc.

Went from 102 lines to ... 10.

More I code, more I realize that maintainability, readability, comments and unit tests are more important than actual code. (And performances ofc. But if 1 line code does it in 1 second and 500 lines code in 0.2 seconds, I’ll take one line solution every time)

That's the spirit.

I agree to all but your optimizations point. I’m tired of halfassed approaches and bloatware. Build things right, even if it’s more involved. Just build it cleanly so another dev can understand and maintain it.

I come to a similar conclusion by a different route.

I'm more of the opinion that if your code is highly provable, it will naturally be readable, testable and performant. Provable code eats its own dogfood all the way down.

I disagree on perf though. I sat in a room once with a director who looked me in the eye and said, "well, it's only 20ms." To which I could only reply, "it's 20ms on every request, between one and 3 times. At our load, we will be dedicating 3 clock days to this computation every month."

@SortOfTested Yes, I get your point “per request”. But I was talking more generally. The most used requests should be optimized the most. Or have some kind of “bulk” api.

We won 10% of execution time just by caching login infos (The token, not the password hien). In this case the challenge was to not forget to reset the cache when necessary.