I find this kind of exhortation to be useless in practice, because while everyone agrees that code shouldn't be too clever, no-one agrees on what kind of code is being too clever.
For example, I'd argue that using C/C++ at all is probably "too clever" - humans are good at simulating the happy path, but very bad at simulating all the possible different ways such code might actually be executed. But all too often people are seen as smart and rewarded for "using such an efficient low-level language".
Conversely, I'd argue that exposing a business constraint as an algebraic datatype that forces you to use it correctly reduces the cleverness required to understand the code.
But I'm sure there'll be someone here who thinks the exact opposite, and bringing "cleverness" into the conversation doesn't actually bring us any closer to agreement.
For example, I'd argue that using C/C++ at all is probably "too clever" - humans are good at simulating the happy path, but very bad at simulating all the possible different ways such code might actually be executed. But all too often people are seen as smart and rewarded for "using such an efficient low-level language".
Conversely, I'd argue that exposing a business constraint as an algebraic datatype that forces you to use it correctly reduces the cleverness required to understand the code.
But I'm sure there'll be someone here who thinks the exact opposite, and bringing "cleverness" into the conversation doesn't actually bring us any closer to agreement.