for a working programmer, learning new concepts ideally needs to happen outside of project work. In reality, there is no time for this.
Ability to program using clear inputs and outputs (rather than void methods with no input parameters) requires a learning effort, I submit to you that this prerequisite is easier than the cognitive effort of maintaining such code.
Is writing “easy” code the same as generating excessive cognitive load for the maintainers? I think it typically is, it is not that hard to incrementally develop a non penetrable maze.
Note: As with regular writing
Referential transparency is an interesting dichotomy. Experiencing different results every time the code is executed typically causes surprise, in my experience developers rarely think about this during implementation.
high quality code shifts cognitive load from maintainer to implementer
consider cognitive overload to be the main cause of bugs.
The main point is that our brain is not well designed to work at the level of statements and lexical tokens, it wants to work on big picture items.
“It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.” The quote is from Dijkstra letter to The University of Texas protesting their Haskell → Java curriculum change.