[layer8]

I wonder about that. A general experience in software engineering is that abstractions are always leaky and that details always end up mattering, or at least that it’s very hard to predict which details will end up mattering. So there may not be a threshold below which cognitive debt isn’t an issue.

[simonw]

> So there may not be a threshold below which cognitive debt isn’t an issue.

That's my hunch too.

The problem isn't "I don't understand how the code works", it's "I don't understand what my product does deeply enough to make good decisions about it".

No amount of AI assistance is going to fill that hole. You gotta pay down your cognitive debt and build a robust enough mental model that you can reason about your product.

[layer8]

I wouldn’t use the term “product” here. Apart from most software being projects, not products, what I was getting at is that details and design decisions matter at all levels of software. You might have a robust mental model of your product as a product, and about what it does, but that doesn’t mean that you have a good mental model of what’s going on in some sub-sub-sub-module deep within its bowels. Software design has a fractal quality to it, and cognitive debt can accumulate at the ostensibly mundane implementation-detail level as well as at the domain-conceptual level. If you replace “product” by “module”, I would agree.

[simonw]

I think of that as the law of leaky abstractions - https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a... - where the more abstractions between you and how things actually work the more chance there is that something will go wrong at a layer you're not familiar with.

I think of cognitive debt as more of a product design challenge - but yeah, it certainly overlaps with abstraction debt.