It’s a nice metaphor, but hopefully we all know what bad abstractions look like.

If you have to refer to the API documentation frequently, even for simple stuff, I don’t see how that’s adding any value.

If you have 100 lines of code but you can expose the logic in 30 lines, that’s probably worth the refactor. However, making your code 3 lines instead of 10 isn’t very important.

RE concept of cognitive load in education, I recently read an interesting review paper Cognitive load theory, educational research, and instructional design: some food for thought by Ton de Jong[1] that did a good job at criticizing the idea as unfalsifiable. By defining three types of cognitive load intrinsic (unavoidable), extrinsic (bad), and germane (learning), it becomes easy to relabel things at will and reach any conclusion. If an education experience is good, then it must be because the cognitive load experienced was germane, if the experience was bad, then it must have had too much extrinsic load.

So it's a nice idea/concept, but difficult to study scientifically.

[1] https://link.springer.com/content/pdf/10.1007/s11251-009-911...

On the topic of cognitive load, has remote work made context switching more difficult? I am in a more senior engineering position and end up getting frequent Slack messages or random calls. It’s very difficult for me to get in the groove with these constant interruptions.

I know other coworkers have similar complaints. My theory is that we could make this less of an issue if our organization could establish communication guidelines/ expectations/ boundaries. Doing this would make you worry less about not immediately responding to Slack and folks assuming you aren’t working. We have some managers who monitor Slack status to make assumptions on if you’re working or not too.

Good read about how learning in general and learning to become a more experienced programmer especially is related to various types of “cognitive load”, a hypothetical model in learning psychology.

I'm in the camp of writing code in a way that requires a higher „germane cognitive load“ in juniors for the benefit of writing less but more robust, extendible and fast/easy to read code for seniors. I acknowledge that this method only works best for programmers with a longer background in practicing our craft. That is why junior engineers who work with me are given more time to learn the levels of abstractions that our systems are made up. This extra time allows to build up mental models around the abstractions — which increases the junior’s germane load and thus slows their speed for shipping code modifications. Maybe in the future, we will see distinct micro services in our systems which evolve together with involved engineers: services written and maintained by junior programmers will better support intrinsic cognitive load and avoid too much germane load, and as the service’s responsible programmers will grow so will the seniority and thus the level of abstractions of a service grow to eventually reduce lines of code written while increasing robustness and extensibility of the code. As such a transition requires a higher germane cognitive load — using the terminology from that article — juniors will need to be assigned new system services which can reflect their current capabilities: significant more but easy to read code due to less abstractions.

The article ends with a well balanced summary catering for all levels of programming seniorities, read: inclusion.

> Producing maintainable software depends on readable code, and readable code depends on controlling cognitive load. Successful abstractions minimise cognitive load - particularly, they avoid extrinsic load, and provide a smooth transition from germane to intrinsic load. Creating ever higher layers of abstraction just to reduce the number of keystrokes we need to make may not always be the right thing to do. Instead, by recognising that code reading is essentially a learning process, and considering how each line of code we write will be processed in the mind of the reader, we increase our chances of creating understandable, maintainable software.

People care less about cognitive load in cut throat cultures.

They'll simplify things for themselves at the expense of others and justify it with a shallow reason like fewer lines of code.

Do they think that it makes them look better when others have trouble understanding their work? Less replaceable? Use it as an opportunity to deepen their skills?

I've never really understood why but I'll confess that as I gain more experience, I also care less about making things easier (for others), especially if doing so would take away from my own progress.

Cognitive load is such a technical term. You don’t want to (and probably cannot) hold 30 different things in your mind at the same time. That’s pretty obvious.

Programmers have such an affinity for technical-sounding terms.