That said, I've worked with a few people who got both sides very well and they were a treasure to work with.
I can reduce that 20 line function into one line of maps / filters / reduces too, but I know I shouldn't if it's going to take 20 minutes for someone else (or me 6 months later) to get through it.
Basically, don't aim to reduce Kolmogorov complexity, aim to increase readability. These two aren't completely mutually exclusive anyway.
This is a great point. As an industry, we seem to be impressed by complex solutions (even if the complexity is unnecessary and the code unmaintainable). Writing clean, obvious code is often met with a "Duh, I see why it was written that way", but without understanding that it took a long time to get the complex solution down to that point.
Very well put.
I have to object to "20 line function into one line of maps / filters / reduces". I don't know what the 20-line function looks like, but I find use of classic higher order functions instead of loops makes code drastically quicker to read accurately.
As with human language, a larger vocabulary can be used in an "overly smartypants" way, but it can also be used to more quickly and robustly convey information between people (or to your future self).
If you haven't read the literature and do not practice with the different techniques, you are probably not writing clean code.
If you're solving problems that require algorithmic ingenuity, you absolutely want these people. And if you can pair them with a good engineer who can integrate their algorithm into a non-trivial system, that's when the magic happens.