9 comments

[ 2.2 ms ] story [ 46.3 ms ] thread
The main issue with rule of seven in an abstract field is that you can always invent more complex words and concepts, which chunk less readily:

1. Name ten types of animal

2. Now name ten programming constructs

The first will surely come more quickly than the second, and that indicates that our working memory is related to our experience: familiar ideas can be recalled and reused faster and more fluidly.

The trade is the same one when choosing between copy-pasted and abstracted code: Lots of obvious steps, versus one big black-box step which has been given some name. You need to justify the new vocabulary to start justifying the black-box.

Highly recommend first reading the wikipedia entry on working memory capacity. Nelson Cowan's work showing that a limit of 4 +- 1 pops up quite a bit, and subsequent investigations of why earlier research got 7 is key here. 7 shows up when people are allowed to subvocalize, and are being tested on "verbalizable" material.

https://en.wikipedia.org/wiki/Working_memory#Capacity

https://en.wikipedia.org/wiki/Working_memory#cite_note-23

This explains a lot for me! I have terrible working memory in general, but in our psych classes when they did the memory experiment on the classroom I could only ever remember ~4 items instead of the expected 7 to 8.
I totally agree that good compostability and keeping things simple is good.

I don't see the relation to the Title's reference (how our working memory can only hold ~7 different items). Those studies are about distinct short term individual items.

This has nothing to do with programming abstractions, those aren't kept in our working memory (not like they seem to be describing). It's not like we can only remember 7 different methods at once.

Is “unnededly” in the final sentence meant to be “needlessly”? I enjoyed the article, but it would be a more satisfying read without that typo.
probably intended "unneededly"?
That occurred to me, but is "unneededly" a real word? The ambiguity is partly why the typo distracted me so much. The final sentence of an essay is a bad place to derail a reader’s train of thought like that.
This article is like a breath of fresh air.

I see the syndrome he criticizes everywhere, and it drives me up the wall. Seven names where two are enough make more work for everybody. Noise words like "factory", "manager", "state", "handle", "object", "metadata" don't belong in interfaces. Clue: every single thing in your program is most of those things! The words take up space on the page and in your brain that could be used for something real. "Get" is the most abused. "GetThis", "GetThat". Clue: every value-returning function gets something! Just call it that thing. "Get" just adds clutter.

BTW, "is" and "has" prefixes on predicate functions are fine. Those read like English in conditionals.

I thought I saw everything until I have run into codebase with scala's tagless final as understood band implemented by enterprise java guys