Very interesting post on a very interesting topic.
Cognitive load of working with code is rarely considered. We ask “How long will it take?” (in fibonacci numbers, of course), we do not ask “How will it impact the overall complexity?”. IMO, thinking about cognitive load can expose project issues that typically go unnoticed.
I totally agree.
Reading the article, I had difficulties identifying your main points. What is it you want me to understand? Or: What is your most important claim or proposition?
I remember that I learned about a very new, different kind of cognitive load when I switched to Haskell. When reading Haskell code, every time there is a new concept I have to slow down and my forehead wrinkles. When I want to use a library that makes use of concepts that I don’t understand, the problem intensifies.
However, before programming in Haskell, the cognitive load wasn’t something unheard of. I remember quite well the difficulties that I had everytime when I got back to work on a somewhat older project. I had to read a lof of (my old) code to recover the confidence that I needed to make a change or add a new feature.
Being an expert in your own code can feel deceptively satisfying.
It took me a while to learn that there are ways to reduce the cognitive load that my own code causes. And as you correctly point out that has a lot to do with complexity and programming paradigms.
I like to add that Haskell-specific cognitive load can be preferable. Ideally, when I learn advanced Haskell concepts, I am familiarizing myself with concepts of general importance and by mastering more of those, I am becoming a better programmer.
Compare that to the cognitive load that a couple of GOTO statements can cause (as an example of my own, bad code). I am not learning anything profound when I become expert of some bad code.
I have feedback regarding formatting:
Sometimes, not always, after a paragraph there is an empty line. I highly recommend consistent spacing after paragraphs to reduce noise.