## Metadata * URL: [https://rpeszek.github.io/posts/2022-08-30-code-cognitiveload.html](https://rpeszek.github.io/posts/2022-08-30-code-cognitiveload.html) * Published Date: 2022-08-31 * Author: [[ajdude|Ajdude]] ## Highlights * 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.