Member-only story

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 MonkeyUser.com.

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.

Create an account to read the full story.

The author made this story available to Medium members only.
If you’re new to Medium, create a new account to read this story on us.

Or, continue in mobile web

Already have an account? Sign in

David Rodenas PhD
David Rodenas PhD

Written by 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.

Responses (2)

Write a response

You article helped clarify my thinking about how to organize our efforts as we try to increase the size and capabilities of our open source development team. We've been applying the "Simplify" filter not only to our code but also to the development…

10

Thanks for the useful article!
I've been hobby programming my whole life but am new to it as a proper career after just finishing a game dev/comp sci degree, and even though I've encountered/thought about most of the things you mention, this allowed me to connect it all and put some things in new perspective.

5