Stop Wasting Brainpower

How many times have you found yourself saying: “I worked all day, but I didn’t get anything done.” I know, we have all been there. We feel bad about it, too. 

On the surface, it looks busy. Your calendar is full, Slack is notifying you, and your todo list is endless. There’s no shortage of movement, and yet, strangely, very little progress. If you’ve ever felt this way, you’re not alone. I wish it was as simple as laziness or poor time management. What’s actually draining us is cognitive load. Our brains aren’t running on infinite RAM. They choke on noise, interruptions, and the dumb complexity we keep piling on.

Psychologists define it simply: our working memory is limited. Every task we take on eats into that limited space. Some load is necessary. The actual problem we’re solving. But most of what burns us out isn’t the work itself, it’s the extra baggage: the clutter in messy codebases, the endless notifications, the scavenger hunts for configuration files, the thousand tiny decisions that drain mental bandwidth.

This is Cognitive Load Theory: once your working memory is maxed out, your brain slows down, mistakes multiply, and frustration goes through the roof. In engineering, the results are obvious. You get slower delivery, more bugs, and inevitably more incidents. Once your head’s full, everything falls apart. You think slower, screw up more, and stop actually learning anything.

A Quick Primer

Before we go deeper, let’s pause for a short detour into psychology. Cognitive Load Theory (CLT), developed by John Sweller in the 1980s, is one of the most widely researched frameworks in learning science. The idea is simple but powerful:

• Working memory is limited. We can only hold a handful of elements in mind at once.
• Long-term memory is vast. Expertise comes from building patterns and schemas we can draw on automatically.
• Overload kills performance. When working memory is saturated, thinking slows, mistakes multiply, and learning or problem solving stalls.

CLT divides mental effort into three types:

• Intrinsic load – the natural difficulty of the task itself.
• Extraneous load – the distractions, noise, and bad design that add unnecessary effort.
• Germane load – the “good” effort we invest in building deeper understanding.

Hundreds of studies in education and psychology confirm what we feel every day: when extraneous load dominates, your performance starts to suck. When intrinsic load is managed well and germane load is supported, you not only complete tasks faster but also understand systems more deeply.

So why does this matter for engineering and management? Because codebases, workflows, and team structures either respect these cognitive limits or abuse them. Once you look at your daily work through the lens of CLT, the pain points become obvious: bloated systems inflate intrinsic load, constant interruptions pile on extraneous load, and little bandwidth is left for germane load.

Intrinsic Load

Every task has a baseline level of difficulty. Debugging a concurrency bug? That’s just hard. Learning a new system? That takes effort. This is the intrinsic load. Your mental effort that’s required from the work itself. You can’t eliminate it. But you can either keep it clean, or pile on unnecessary complexity until the “hard stuff” becomes damn near impossible.

Healthy systems keep intrinsic load proportional to the problem. If I give a new engineer a ticket that requires adding a new field to a form, they should touch two or three files, wire it up, and push it through the pipeline. Done.

Nonetheless, in most messy systems, that same simple ticket explodes into ten files scattered across frameworks. Front-end components here, backend endpoints there, business logic hiding in helpers no one has touched in years. By the end, you’re not even solving the ticket anymore. You’re playing archaeologist, digging up some buried mental model nobody bothered to write down. One, that’s hard. Two, that’s time consuming. That’s not intrinsic difficulty. That’s us making the problem harder than it has to be.

The same thing happens when debugging. You start with a failing test. Then you trace it through a controller, then a helper, then a service, then an adapter, then an external API. Each hop eats up working memory. By the time you’re five layers deep, you’ve forgotten the original bug you were chasing. The load isn’t coming from the problem anymore. It comes from the system’s refusal to stay simple.

Even small tasks can blow up intrinsic load. Think about flipping a simple flag as an example. One YAML points to another, then an override, then a hidden base in some other directory. What should be a straight line turns into a scavenger hunt. By the time you are done, you have reverse engineered the system. That is not intrinsic difficulty. That is a pointless load dumped on your brain. And the punchline is that nobody can even say with confidence how the system actually works. It becomes a clown show. You need a treasure map and a bottle of whiskey just to flip a flag.

Intrinsic load is inevitable. Inflated intrinsic load is a choice. And too many of our systems choose to dump that extra weight on the engineer’s brain instead of carrying it in the code. I talked about why we overengineer systems. That’s one of the penalties we pay for it. 

Extraneous Load

If intrinsic load is the work itself, extraneous load is all the crap that gets in the way. It’s the wasted mental effort of juggling distractions, navigating bad design, and fighting systems that seem built to scatter your focus.

Imagine you finally get into the zone, tracing a bug, holding the entire problem in your head and then someone is pinging. So, you respond back for the quick sync. There. You lost it. Research from UC Irvine shows it takes 23 minutes to regain focus after an interruption. That’s not just 23 minutes lost, it’s a full reset: you’ve got to reload the architecture, the reproduction steps, the mental stack of variables you were juggling.

Psychologist Mihaly Csikszentmihalyi described flow as the sweet spot where skill and challenge align, and work feels almost effortless. We call it being in the zone. It takes 15 minutes of deep focus to get there, but one message can knock us out instantly. That’s an extraneous load. It’s a stolen attention we will never get back.

Extraneous load is the tax we should fight hardest to eliminate. It adds nothing to understanding, nothing to delivery, nothing to quality. It’s pure waste. And you know it yourself. This shit happens all the time! And you know it’s true. This crap happens every single day, and we just accept it as normal. It’s not.

Germane Load

Not all mental effort is bad. Germane load is the part we actually want. This is the brainpower spent making sense of patterns, building schemas, and deepening understanding. It’s the load that pays dividends.

You feel germane load when you’re reviewing clean, modular code and notice the consistent patterns. The effort actually sticks. Next time you move faster because your brain’s got the pattern cached. You feel it when you pair program and pick up shortcuts or thought processes from someone more experienced. Or when good docs explain the “why” behind a decision, and you walk away with a mental model that sticks.

The tragedy is, most teams never leave engineers enough room for germane load. By the time you’ve burned through inflated intrinsic load (messy code) and suffocating extraneous load (distractions and noise), there’s no bandwidth left. Instead of learning the system, you’re just surviving it.

A healthy engineering environment flips this. Reduce extraneous load, manage intrinsic load, and you free up cognitive space for germane load. That’s when onboarding feels smooth, reviews become productive, and knowledge compounds instead of leaking away.

Here’s an interesting take. The best systems don’t just make work possible. They make understanding inevitable.

When Load Gets Out of Balance

When intrinsic and extraneous load eat up all the space in working memory, there’s nothing left for germane load. That’s when the system turns hostile.

You see it in code reviews that crawl because reviewers spend all their energy reloading context instead of evaluating logic. You see it in bugs that slip through because nobody can juggle ten flaming torches of context at once without dropping something. You see it in new hires who avoid touching “scary” parts of the code because the cost of understanding feels unfathomable.

And you definitely see it in burnout. Every day becomes a grind of reloading mental stacks, chasing scattered configs, and fighting distractions, with little actual problem-solving to show for it. Carlson’s Law sums it up: 

Interrupted work will always be less effective and take longer than if completed continuously.

The cost isn’t abstract. It’s slower delivery, rising technical debt, frustrated engineers, and brittle systems. It’s the silent tax of cognitive overload, paid in bugs, missed deadlines, red error budgets, and people quietly giving up.

Designing Systems That Respect Cognitive Load

If cognitive overload is the hidden tax, the way out is to design our work so it fits within the limits of human memory. That means reducing the noise, managing the complexity, and protecting space for the kind of effort that actually pays off.

• Reduce extraneous load. Default to async. Cut the “quick syncs” that kill flow. Set strong defaults in tooling so engineers don’t waste brainpower hunting configs. Every ping you prevent is 23 minutes of focus you save.
• Manage intrinsic load. Some problems are hard, but the system shouldn’t make them harder. Keep modules small and boundaries clear. Use consistent naming and patterns so engineers don’t have to reload mental models with every hop. A new ticket should be measured in files touched, not archeological digs through ten frameworks.
• Encourage germane load. This is where knowledge compounds. Pair programming, mentorship, and clean docs all turn effort into long-term understanding. Code reviews should teach, not nitpick. Reviews should expand shared mental models, not drain them.

The point isn’t to eliminate load entirely. It’s to make sure the load we carry is worth carrying. Systems either respect the limits of the human brain or exploit them. The former makes work smoother, faster, and more rewarding. The latter burns people out.

Conclusion

The real cost in engineering isn’t the hours we grind out. It’s the brainpower we burn. Every ping, every bloated abstraction, every scavenger hunt through configs drains the same tiny pool of working memory. Once that pool is dry, you slow down, you screw up, and you stop building systems you actually understand.

Cognitive Load Theory makes it simple. Cut the distractions, keep the hard stuff clean, and leave space for the kind of effort that actually makes us better. That’s the only way engineers do their best work.

We don’t need another meeting. We don’t need longer hours. We don’t need shinier tools.
We need fewer wasted brain cycles.