[dkarl]

I think this is a danger with any powerful language. In order to aid readability, abstractions need to be chosen, or designed, to be intuitive to readers and to align with their understanding of the domain. Sometimes people can be overly determined to decrease the verbosity of their code, and after spending enough time immersed in it, almost any detectable pattern can start to feel "intuitive." Using these patterns to compress the code can feel like a process of discovery and innovation to the person doing the writing, but if the abstractions are not intuitive for readers, it has the same effect on readability as gzipping a text file. Patterns are found, verbosity is decreased, but readers are not aided by the abstractions and must mentally decompress the code in order to understand it.

In my own day-to-day work, I see this issue with Scala programmers (myself included) who suffer from a tendency to see any kind of struggle with code as a valuable learning process. All of us got to where we are, slinging around monads in a "hard" language, because we have an appetite to expand our mental repertoire and a tendency to lean into difficulty. Selectively applied, this is a wonderful attitude to have towards learning programming. It is a counterproductive attitude to have towards your own codebase, though. In your own codebase, you have to flip your assumptions on their head and assume that if code is difficult to read, then more work should have been put into writing it.