One is "having low cognitive load," and the other is "having low technical debt." Therefore, instead of relying on the abstract concept of being clean, we should focus on reducing cognitive load or technical debt. Writing code that reduces these will make it clean.
...Though, of course, that's easier said than done! Cognitive load can be reduced through a common language, which means we need to define that common language (this is precisely what domain-driven development is about). Technical debt, meanwhile, is the gap between the ideal and the implementation. Since the ideal, starting with the requirements, keeps "changing," focusing solely on the implementation doesn't hold much meaning.
Still, as an engineer, I believe we should strive to reduce these burdens as much as possible. The devil is in the details. There’s also the fable of the tortoise and the hare. By writing with the intention of reduction from the start, like in shift-left practices, we can avoid losing momentum later on.
Thank you for this incredibly thoughtful breakdown - I genuinely loved reading it. Your distinction between low cognitive load and low technical debt really resonates with me. I’ve felt that tension so many times in real projects, especially when requirements keep shifting and the “ideal” moves further away every week.
What you wrote about common language and reducing mental overhead is something I’ve seen play out in teams over and over again. When we’re not aligned on concepts, even the cleanest code becomes heavy. And when tech debt grows faster than features, even elegant solutions feel fragile.
That’s why I personally lean toward the simplest approach that reduces both the thinking burden and the future pain - even if it’s not perfect. It’s the only thing that consistently helps me stay sane through migrations, refactors, and constant change.
Really appreciate you taking the time to share this - it adds so much depth to the conversation.
It's nice to see another dev talking about cognitive load! I've spent the last two months writing about how writing code that is aligned with cognitive and perceptual principles are easier to read and maintain. When I started applying the SRP to my code more strictly, I was amazed to discover how much easier my code is to understand. With AI, I can ship maintainable, readable code extremely fast - it's not one or the other anymore.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are two meanings to "clean."
One is "having low cognitive load," and the other is "having low technical debt." Therefore, instead of relying on the abstract concept of being clean, we should focus on reducing cognitive load or technical debt. Writing code that reduces these will make it clean.
...Though, of course, that's easier said than done! Cognitive load can be reduced through a common language, which means we need to define that common language (this is precisely what domain-driven development is about). Technical debt, meanwhile, is the gap between the ideal and the implementation. Since the ideal, starting with the requirements, keeps "changing," focusing solely on the implementation doesn't hold much meaning.
Still, as an engineer, I believe we should strive to reduce these burdens as much as possible. The devil is in the details. There’s also the fable of the tortoise and the hare. By writing with the intention of reduction from the start, like in shift-left practices, we can avoid losing momentum later on.
Thank you for this incredibly thoughtful breakdown - I genuinely loved reading it. Your distinction between low cognitive load and low technical debt really resonates with me. I’ve felt that tension so many times in real projects, especially when requirements keep shifting and the “ideal” moves further away every week.
What you wrote about common language and reducing mental overhead is something I’ve seen play out in teams over and over again. When we’re not aligned on concepts, even the cleanest code becomes heavy. And when tech debt grows faster than features, even elegant solutions feel fragile.
That’s why I personally lean toward the simplest approach that reduces both the thinking burden and the future pain - even if it’s not perfect. It’s the only thing that consistently helps me stay sane through migrations, refactors, and constant change.
Really appreciate you taking the time to share this - it adds so much depth to the conversation.
It's nice to see another dev talking about cognitive load! I've spent the last two months writing about how writing code that is aligned with cognitive and perceptual principles are easier to read and maintain. When I started applying the SRP to my code more strictly, I was amazed to discover how much easier my code is to understand. With AI, I can ship maintainable, readable code extremely fast - it's not one or the other anymore.