What is 'cognitive load,' an important factor for developers to complete projects quickly?
Artem Zakirin, CTO of software development company Inktech, explains the 'cognitive load' that leads to wasted time and effort and how to reduce it.
Cognitive load is what matters
According to Zakirin, cognitive load can be summed up as 'how much thinking a developer needs to do to complete a task.'
The average developer can keep in mind about four things in their code (variable values, control flow logic, call sequences, etc.) and as soon as the cognitive load increases beyond this level, the code becomes difficult to read.
So while it’s vital to reduce the cognitive load of your project as much as possible, the cognitive load of the core parts of software development cannot be changed, so you end up focusing on irrelevant aspects, like overly complex code.
Below is an example of code with a high cognitive load, as shown by Zakirlin. This code may look simple at first glance, but the conditional divisions are complex, so the cognitive load will be high when someone else reads it.
if val > someConstant // 🧠+
&& (condition2 || condition3) // 🧠+++, prev cond should be true, one of c2 or c3 has be true
&& (condition4 && !condition5) { // 🤯, we are messed up by this point
...
}
Therefore, if we introduce intermediate variables to reduce the cognitive load, the code becomes more readable and easier to maintain, as shown below.
isValid = val > someConstant
isAllowed = condition2 || condition3
isSecure = condition4 && !condition5
// 🧠, we don't need to remember the conditions, there are descriptive variables
if isValid && isAllowed && isSecure {
...
}
In addition, developers often encounter what Zakirin calls 'inheritance nightmares.' Here's an example: 'AdminController inherits UserController, which inherits GuestController...' As the hierarchy gets deeper, the cognitive load also increases.
AdminController extends UserController extends GuestController extends BaseController
According to Zakirin, the unwritten rules among developers that 'methods should be shorter than 15 lines of code' and 'classes should be small' are often wrong.
This is because if there are many small modules, it is necessary to consider not only the role of each module but also all of their interactions, which results in complexity and a large cognitive load compared to the functionality achieved. Zakirin says, 'It is important to hide information and keep the interface simple, but there is a limit to the amount of information that can be hidden with small modules.'
Zakirlin recalled the time he ran into this problem: 'I had two projects with about 5,000 lines of code each. One had 80 small classes and the other had 7 large classes. I left them alone for a year and a half, and when I came back to them, it required a huge cognitive load to pick up the one with 80 classes, but the other had a simple interface and just a few classes, so I was able to understand it easily.'
Zakirin introduces a few quotes that warn of the cognitive load problem. The first is from computer scientist
For example, here is the UNIX I/O interface; modern implementations of this interface contain hundreds of thousands of lines of code, but only five basic system calls:
open(path, flags, permissions)
read(fd, buffer, count)
write(fd, buffer, count)
lseek(fd, offset, referencePosition)
close(fd)
For his second quote, Zakirlin introduced the words of Rob Pike, a software engineer known as the 'father of Go,' who said, 'Limiting the number of options reduces cognitive load.'
Speaking of his own experience of wasting time because of too many options, Zakirin said, 'When a new feature is released in your favorite language, you can't help but want to try it out, but when there are so many features, you can end up spending 30 minutes writing a few lines of code to use one feature. Not only is this a waste of time, but you also have to go through that thought process again when you come back to it later.'
What may not be a cognitive load for you may cause problems when someone else takes over.
Zakirlin says that when new people join a project, they should first try pair programming to gauge how confused they get: if the two people are confused for more than 40 minutes, there's room for improvement in the code.
'By keeping the cognitive load low, new employees can start contributing to the codebase within hours of joining the company,' Zakirlin said.
Related Posts:
in Software, Posted by log1l_ks