Non-technical Mitigation Strategies

[nitsanavni]

Hi!

Great stuff!

WDYT about the following non-technical strategies to address cognitive load when faced with unfamiliar code:

1. While trying to understand a piece of code:
   a. Take notes of micro-understandings - this can serve as an external persistent memory, extended cognition
   b. Even better: encode your micro-understandings into the code with micro-refactorings, comments, docstrings, renames, etc.

   This can combat loss of context when interupted for example.

2. Chunking:
   Assuming we can hold only four chunks in mind at a time. Chunks can differ greatly in cognitive value. I beleive that through delberate practice, we can chunk together smaller chunks into larger ones, allowing us to tackle a larger range of cognitive tasks. See @jbrains writing and talks about this.

3. Shared burden through Teaming
   Maybe a team has more cognitive power than a single person?

More?

Thanks!

[nitsanavni]

Three more come to mind:
4. Work in tiny steps see GeePaw's MMMSS, Arlo's Read by Refactoring and Naming as a Process, etc.
5. Offload cognitive load to AI, let it do (some of) the thinking
6. Offload to automation and tools

[zakirullin]

Hi there, @nitsanavni! Thank you for your feedback and such insightful thoughts!

Reading your points, as well as the links you provided, triggered a few thoughts, so I'll write them down in raw.

That chunking thing resonates a lot of with my own experience. Even when it comes to non-technical stuff. It seems like it is closely related to bird's eye overview, and writers from non-technical field seem to practice this principle a lot. You take a sneak peak at an article's headline or a few intro lines - and you can immediately chunk the whole article in just one idea. You can read a few headlines and you get the basic idea of what's happening in some domain, it might be a totally wrong and subjective picture, but that's not the point here. You get overarching view of the system (chunking?), and you can dive into the details if needed.

I had a rather different experience when reading technical proposal and the code itself. You open a technical proposal, you read a few lines, and one question appears in your head. "What is that for? What problem does it solve? How does that fit into overall system?". And usually you have to dig deep in order to for this chunking to happen.

Whenever I face a new framework, orchestration system like K8S or any system in particular, I want this chunking to happen as quick as possible. And with the current learning mediums it's a rather tedious, slow experience. Taking notes helps a lot, I completely agree with you about this point about micro-understandings! With such approach I can come back years after and load those mental models from the notes directly into my head. When it comes to Kubernetes, for example, it would be good to know that there are only five binaries (chunks?) in the system. Coupled with a simple demonstration of their interaction and the resulting tangible benefits would foster learning (chunking) a lot.

The way programmers love to learn new systems is to take some working simple example that they understand, and hack&run it until a more complex solution emerges. We start with a naive view of the system - we see only few interacting overarching chunks, and we hack&run until we get a finer realistic picture. Sadly, current mediums throw at you all the details at once, and you have to go through that taxing chunking process all on your own.

That's not a structured response to your points, just a train of thoughts.