Hm, what the post's author says is reasonable on its own, but I'm confident Kernighan's intents were really about avoiding clever code when simple, dumb code does the job. Or, as Rob Pike[0] puts it:
> Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
> Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
It's a bit ironic then for this post to rely on such a convoluted interpretation instead of the simple, dumb one.
Yes, Kernighan absolutely didn't mean anything this article talks about.
It's been a while since I read Elements of Programming Style, but most of it is in the form of "here is some bad code we encountered, here is how we made it better, and this is the lesson we can learn from it". Some of these are pretty specific and outdated (e.g. IIRC "avoid Arithmetic IF" is one of them) and others are just basic common sense advice that holds up well today. It's all very down to earth and pragmatic and centred around real-world code.
Taking a quote out of that context and then musing that maybe perhaps possibly the author could have meant something different/deeper with it is not really helpful.
Yeah, it's a clever (ha!) interpretation, but I also don't think Kernighan meant it that way. Basically, what the article says is that yes, you should make your code as clever as possible, so that your future self (or others who will be fortunate (?) enough to work with it) may grow professionally by finding the obscure issues that are hidden within, or by trying to wrap their heads around it in order to be able to extend it (often in ways that are at odds with your clever design). I don't know about others, but I can imagine better ways of professional growth...
> Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
> Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
It's a bit ironic then for this post to rely on such a convoluted interpretation instead of the simple, dumb one.
[0]: https://users.ece.utexas.edu/~adnan/pike.html