Tech debt and cognitive load

Everyone is suddenly talking about cognitive debt as a distinct thing from technical debt. To me, a programmer, these are almost two names for the same thing. When your system gets too complicated, thinking about it and making changes to it become incredibly hard. Too much complexity incurs a prohibitive cognitive load on the programmers who have to deal with the codebase, be they meat or LLM. Without a (shared) theory of how a system works, it can’t be worked on productively.

Note that complexity and cognitive load are exactly why programmers ever got hired in the first place! Nobody hires software engineers to help them use Excel, or to write prose. But if you have a whole newspaper’s worth of prose to manage every day, or more data than a thousand computers running Excel can cleanly handle, or multiple versions of an analysis that need to be considered simultaneously, or all these things need to be versioned over time…now suddenly the cognitive load of juggling all those moving parts has become too big, so you hire people—programmers—who know how to (and are willing to) build and use tools that can help manage it all.

The trick is that if you push too hard on these people you’ve hired, they’re forced to take shortcuts now that they’ll hopefully be able to fix up later, lest they be overwhelmed later by the complexity incurred by shortcuts accumulating in the codebase. The name for these shortcuts is technical debt: buying time now (taking a shortcut) by paying for it in the future (spending programmer time cleaning the system up so that it remains tractable by humans, and so that running the system isn’t long term prohibitively expensive).

I’d argue that “technical debt” in a static codebase, one that will never see updates again, is fine: it works, and will continue to work forever because nothing about its environment or feature set will ever change. Technical debt is only bad in a system that needs to continue to evolve, which is basically all software systems: bugs need fixing, operating systems get updated, machines break, new use cases emerge, etc., and if you don’t have the ability to reason about this system then you’re stuck. Paying down technical debt is done exactly so that you can continue to reason correctly about the system and continue to evolve it.

Carrying technical debt around is fine, exactly in proportion to whether you can carry the cognitive load it incurs.

So I think cognitive debt is a better frame for the problem of having too much complexity. And yes, it matters way more now that AI tools can generate totally reasonable and functioning code given coherent instructions. And luckily for people in my profession, I think it means we’ll remain employable for at least another two or three years.