Three Ways to Reduce the Programmer’s Cognitive Overload

David Rodenas PhD
7 min readJun 23, 2022

Avoiding the cognitive overload of a programmer is key to avoid bugs and accelerate the development.

Focus by

One of the podcasts that I usually listen is “No Stupid Questions.” This Monday, I listened the episode “How Simple Is Too Simple?” In that episode, they challenged the Occam Razor, and exposed the human bias towards the most simple explanation in opposition to the most complex one. Although that in physics often the most simple explanation is the right one, in other branches of the science like economics or psychology that changes. Why the Roman Empire fell, or why the crime decreased during the last decades, there is no one reason, but several. They showed how, despite the clear evidences, people preferred having to deal with one reason, rather than multiple reasons. That hit me.

A month ago, I published a way to reduce the cognitive overload of a programmer. I did not present it as “the way” to reduce the overload, rather than a way. The content of that story was a discovery that I recently did, and I wanted to share with others. Generally, it was well received, but some people had an unexpected opposition reaction. The origin of the opposition was that they knew a different method, and somehow, they decided that was the only one. Curiously, all of them pointed to the same method. They were right about that method, but they were wrong assuming that it was the only one. Currently, I have found three main methods, and several more than can help.

It turns out that cognitive load is a complex question, and it has several impacts.

The three main ways that I know to tackle the programmer’s cognitive overload can be resumed as: Split, Simply and Transfer.

1. Split

This is the tool number one to reduce the cognitive load. Instead of letting the programmer face everything at once, we split the domain. If a software artifact is big, probably will contain hundreds, or thousands, of different concepts. But we do not want a team touching too many concepts at the same time, so that is why we need to split it.

There are two different ways to split, and as far as I have discovered, two methods: vertical and horizontal.

David Rodenas PhD

Passionate software engineer & storyteller. Sharing knowledge to advance our skills. Join me on a journey of discovery in the world of software engineering.