Followed book's principles for years, wrote an article

[Artem Zakirullin]

Hi there!

John, thank you for such an amazing book! Really, you've introduced great fundamental principles. The book was highly influential for me.

After years of following book's core principles I've drafted this article, what do you think?

https://github.com/zakirullin/cognitive-load

[John Ousterhout]

Hi Artem,

I finally got my head back above water enough to read your article. Overall, I like it! I certainly agree with your goal of reducing cognitive load, and I don't have any major disagreements with the article. Nonetheless, here are a few comments:

• Picking the number 4 as the limit for working memory feels a bit artificial to me. For example, my guess is that most programmers can keep on the order of 1000 lines of code in their head at once, which would include way more than 4 facts. But, your overall point is still valid: more cognitive load is worse than less cognitive load.
• In the "Business logic and HTTP status codes" section, why not just define meaningful symbols for the various numeric values, analogous to symbols like EINVAL for Linux errnos? Also, I'd argue that any place an HTTP status is printed, such as Web pages generated in response to errors, a longer human-readable string should also be printed. This would probably meet the needs of the QA people in the example. Sometimes printing more information can reduce cognitive load.
• In the "Complicated if statements" example, it's not clear to me that the second approach really has less cognitive load because the additional variables add at least a tiny amount of additional cognitive load, and it's not clear to me that it will be all that hard to read the code in the first example, if it's formatted cleanly.
• I had trouble understanding the arguments against frameworks; if a framework is good, it should reduce cognitive load in comparison to a system without a framework, no? Maybe the problem is bad frameworks, as opposed to frameworks per se? I have definitely seen frameworks that create a huge amount of unnecessary cognitive load.
• I don't know enough about DDD or hexagonal/onion architecture to comment on those sections.

Thanks for writing the article; I think it's a useful contribution. And, thanks for the link to APOSD.

-John-

[Jeff Doolittle]

Here's another helpful resource in a similar vein:

https://www.amazon.com/Programmers-Brain-every-programmer-cognition/dp/1617298670

And a related podcast I hosted with the author:

https://jeffdoolittle.com/2021/06/02/the-programmers-brain-with-felienne/

[Artem Zakirullin]

Hi John, thank you so much for your review!

> Picking the number 4 as the limit for working memory feels a bit artificial to me.

Well, that's indeed a questionable topic. I relied on paper titled "The magical number 4 in short-term memory: a reconsideration of mental storage capacity" by Cowan (more on that here: https://github.com/zakirullin/cognitive-load/issues/16)

> In the "Business logic and HTTP status codes" section, why not just define meaningful symbols for the various numeric values, analogous to symbols like EINVAL for Linux errnos?

That's exactly the point of this section! By the end of this section I gave an example:  "code": "jwt_has_expired". Maybe I should somehow restructure the section so to make it more concise.

> I had trouble understanding the arguments against frameworks; if a framework is good, it should reduce cognitive load in comparison to a system without a framework, no?

Well, from what I see the industry is shifting to somewhat micro frameworks approach, or some component-based things. There are certain big-bloated frameworks that are really hard to master, and the amount of investment needed to learn in comparison to the benefits it gives is kind of questionable. The problem arises when an app is deeply entangled with any of these frameworks, and cannot be used in any way beyond that framework. 

[Artem Zakirullin]

Jeff, thanks for the resources provided! I didn't know about the book before start writing the article. 

I will have a look at your podcast, as I am deeply interested in such things.