I've noticed recently that especially in online discussions, the term "cognitive load" is used as a catch-all excuse to rag on code that someone doesn't like. It appears to be a thought-terminating cliché.
There's definitely room to talk about objective metrics for code simplicity, which are ultimately what many of these "cognitive load" arguments are about. But cognitive load seems to misrepresent the problem; I think it's hard to prove/justify/qualify without some scientific evidence over a large population sample.
With that said, the article presented fine tips, but they seem to be stock software engineering tips for readable code.
In cognitive psychology, cognitive load refers to the total amount of mental effort being used in the working memory
seems like a correct usage to me.
Anytime an ATM displays weird confirmation buttons like "Sure" instead of "Yes" or bloated confirmation text instead of "transaction completed" this increases cognitive load. I agree that it is debatable what kind of code exactly causes the least strain, but at least the term doesn't seem to be especially scientific.
"The pupil response not only indicates mental activity in itself but shows that mental activity is closely correlated with problem difficulty, and that the size of the pupil increases with the difficulty of the problem"
My problem is precisely that these scientific methods are not used when "cognitive load" is being used as rationale. Wouldn't you agree that it would be a mistake for me to claim that cognitive load is an issue with something if e.g. I have not shown that pupils dilate (or some other reasonable experiment indicating correlation)? Unfortunately, doing these experiments is difficult, which justifies "hard to substantiate."
Yes I do think claims should be justified by experiments. Perhaps I'm reading the wrong fora but it seems to me that serious HCI-studies on language design should be happening a lot more than it does.
I agree with you. People use "Cognitive load" as meaning to say "people should be thinking the way I think, because to me that is very easy and straightforward".
The load gets bigger not because the code is more complex, but because we reason about problems differently, we build different mental models of the solution, and if these models are too different, then the cognitive load gets heavy.
The other side of the coin is that books like Code Complete go a long way into making those mental models more clearly stated.
Solving the underlying problem (big variety of mental models) means standardizing how we thing about solving programming problems. The GOF book, head in that direction... then again, they become used for the sake of implementing a pattern instead of solving a specific problem. I think this is one of the things that keeps software development in the craft area, as opposed to engineering. but that would be a different rant
There's definitely room to talk about objective metrics for code simplicity, which are ultimately what many of these "cognitive load" arguments are about. But cognitive load seems to misrepresent the problem; I think it's hard to prove/justify/qualify without some scientific evidence over a large population sample.
With that said, the article presented fine tips, but they seem to be stock software engineering tips for readable code.