It was never intended as a definitive _thing_. I don't think anyone believes it has an exact definition. Just like good writing. There is no canonical good. Shakespeare and Hemingway are both "good" but absurdly different. But still, "clean" is a useful abstract concept for us to aim for in each context we encounter. At the end of the day, we need some kind of way of talking about "desirable" or "good" code. And I feel like 'clean' is as good as any other word.

The author lists a litany of traits that could be considered "good" things to aim for, but most of them are pretty granular, fuzzy, or superseded by others. The author says:

Words like ‘encapsulated’, ‘testable’, ‘mockable’, ‘reusable’ have meanings that we can all agree on. When we use more specific words that describe the various code traits that affect our project then we can be sure that we’re all on the same page.

Unfortunately, however, we're never really on the same page. Even these more precise terms are very context specific and amorphous. "Testable" may mean granularly accessible, modular, mockable, idempotent, or quick to spin-up for CI, or only a subset of these. Highly dependent on testing approach too (unit, TDD, BDD, E2E...)

This is why I like thinking in terms of tenets: broad concepts that are applicable to everything but enable context-specific meaning. E.g.

  - Reliable
  - Efficient
  - Maintainable
  - Usable

With these tenets, for example, we can then *contextualize* and find the "cleanest" code for whatever particular application we're working on. If we want to break these broad tenets down further then we can, and I hold the position that this _is_ very useful:

  - Reliability: Correctness, Stability, Resilience 
  - Efficiency: Time, Space, Second-order effects (ecology etc.)
  - Maintainability: Adaptability, Familiarity 
  - Usability: Storytelling, Intuitive, Accessible

Most of these are independently VERY context-specific. Being time-efficient is about the available hardware, interfaces, UX, etc. Being accessible or usable is about WHO is going to use or access your abstractions and underlying implementation.

To achieve these tenets, there are many principles and approaches to draw on to help us find the 'clean' solution each time: E.g. The Law of Demeter (LoD), SOLID, The abstraction principle, Functional programming, etc. These exist as tools to help us get closer and closer to the unreachable (yet desirable) goal of "clean".

So, I suppose I agree with the author but only semantically. Cleanliness does not have a fixed definition, but it is still useful to talk about as a goal or absolute to aim for. A bit like all manner of other superlatives.