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.