Cognitive Load — Why It’s Destroying Your Code and What to Do About It
Let me tell you a little story.
It began a few years ago when I started working on my first serious personal project. It involved learning Java & Android development, so I can build a cool Todo app that will provide me with location-based reminders. Back then, I didn’t know of any Todo app that already offered that, so it seemed like an interesting project.
Problem was, I paid little attention to best practices and code structure. Which made my project overly complex and hard to maintain. I had to constantly think and re-think every function and every class, constantly restructuring my project. It wasn’t at all bad for a first serious project, but over time I felt most of my time was spent on maintenance, rather than the actual features. Luckily I found alternative apps that had just what I needed, so I shelved this project as a nice learning experience.
Fast forward a few years, I found myself dealing with a different issue, that had the same root cause. I was writing a small extension to an existing API in a shared library, and the last time I did something similar was in my previous job at a different company, which had different coding conventions.
I estimated this task at about an hour (I tend to underestimate, but still) and it took me about 3x as long to produce decent code.
The reason? I spent way too much time writing and re-writing code, thinking and re-thinking every small change. This time though, it wasn’t my OCD’s fault. It was simply because I wasn’t familiar with the coding conventions my current company uses for tasks like that, and I didn’t want to mindlessly apply the best practices from my previous company.
I’m sure you’re probably thinking to yourself — then what’s the root cause? is it stupidity? not learning best practices? probably a bit of both.
Though I do have to justify this article’s title (and my Psychology degree), so let’s talk a little about your working memory and its surprising limits.
Cognitive Load Theory — Your brain’s tab limit
In a nutshell, this theory is based on the fact that our working memory’s capacity is crap. We can only hold so many chunks of information at once. That means that if your cognitive load is high, or in other words, if you’re trying to juggle too many bits of information at the same time, your performance at the task you’re supposed to do will suffer, greatly.
That also makes intuitive sense, if you’re busy thinking about what you’re having for lunch, why your date isn’t answering you, and why you still like ketchup so much, your code is going to look like crap.
In my case, I was too busy thinking and re-thinking about all the ways the code could be structured, all the possible coding conventions that might work. So my working memory was overwhelmed and it took me a considerable amount of time to finish the task. Whereas in cases where I am familiar with the coding conventions, I don’t waste any mental resources thinking about how my code should be structured, I simply focus on the logic and write awesome code.
That doesn't mean you should write code on auto-pilot, not at all.
You still need to plan and design your features.
What I am saying, is that you should settle all the technicalities in advance, so you don’t need to re-think them every time you write code:
- How you structure code into packages
- When does it make sense to wrap SDK classes, if at all
- Layering architecture (if it’s used, and what it’s comprised of)
- Class/Package/Layers naming conventions — Do you use Converters/Transformers? Processors/Handlers? neither/both, etc.
- Do we use REST naming conventions or something else?
This is far from an exhaustive list, but the main point is this — if you want to be more productive you need to reduce your cognitive load:
- Settle all possible technicalities in advance
- Make sure you’re familiar with them
- Accept your love for ketchup (or whatever guilty pleasure is)
- Put your phone aside, turn off Slack and other distracting apps.
- Focus on your task and do your best work.