Short-term memory overload while debugging

TLDR:

Even if you are super smart your short term memory can only remember 5 to 9 things for 30 seconds. The decisions you make while thinking about code are far too complicated to trust to memory. Ken shows how Understand helps you not rely on short term memory and walk code in an organized fashion that misses nothing.

Details:

I had a class in Psychology in college where they covered short term memory and described a man who defied all the expectations of the 7 things in short term memory (+-2). He was remembering huge strings of ones and zeroes (binary). You know where this is going… he worked at Bell Labs and was chunking them into binary that he recognized instantly… so while he did have a great short term memory, he was chunking binary into 9 or 10 numbers and remembering them.

Short term memory is limited and it usually is encoded by audio (not visually).

Source code, even “simple” source code, usually exceeds your short term memory quickly.

For example, I’ve been looking at the source code for “Git” over the last few days. If I investigate its use of “stdio.h” – maybe for security compliance, or something similar, it starts off easy:

One click later… things are getting a bit thornier:

and one click later… overload!

In some cases you can “grep” or “find in files” – but what I’m looking at here are the possible uses of it, and there are too many names/symbols/macros to search for – I need to do it based on the relationship to “stdio.h”.

I didn’t count the uses, it’s too many to remember. I’m gonna have to scan thru looking for candidates, or grind thru looking at each. That’s okay, I don’t have to remember anything now – the list is there, I’ll just walk it.

Here, by the way, is the final fully expanded view of the potential usages of stdio.h. Given how large this is I’d be thinking about a script that would look at what <stdio.h> provided, and filter this graph to just code that used things it declared. That’s an article for another day!