I applaud the author for thinking afresh on this topic.

I am also comfortable with the closing comments that you can't always dumb down your code or you stagnate and never learn new tricks/techniques. It is a good thing to keep in mind.

But I have also seen people waste a lot of their (and others') time trying to be clever in ways which as an outsider from additional context I have I can anticipate won't pan out. And I've let it slide and watched it end "not-well", leading to long unnecessary debugging cycles, missing deadlines, and creating boilerplates of YAGNI abstraction and complexity that didn't "make the easy things easy and the hard things possible" but instead made the easy things complicated.

I myself have been accused of that when trying to design optimal "scalable" architectures up front. And I myself have patched over inherited "clever" things with flaws that I handled by adding yet more incremental "cleverness" when, N years later I wish I had just cut the knot of Gordian complexity on day 1.

I think Kernighan's Law is perhaps best applied as a cautionary question to ask yourselves or others in the journey: are you getting too clever, and can you (and others around you) really debug the cleverness you are pursuing?

Complexity and cleverness may be needed, but have you considered re-approaching the problem from a standpoint that minimizes the need for cleverness?

Put another way, there is cleverness that brings "simplicity of code" that does not bring "simplicity of debugging or maintenance" by yourself or others. It's wise to be aware of that.

I view cleverness as somewhat like "innovation tokens"... you should "pick a small handful" of them strategically but not overuse them. I don't see that caution in a pure statement of "Kernighan's lever".

Also seemingly tacitly ignored in the poster's perspective is any acknowledgement that software is, or can be in a huge chunk of scenarios, a "team sport". It's all fine for you to get more clever by pushing yourself, but if you don't transfer your knowledge/cleverness to the broader development+support group, it isn't good for the organization, and perhaps not even you if you consider your code's value proposition will itself harden and stagnate and get refactored out.

(Of course, for some programmers, that's a virtue; write your code in an obscure language/style so that nobody else will take credit or touch it and mess it up. I literally had an acquaintance who, sensing in me a similar competence (or elitism?), boasted to me about his cleverness in doing this at his workplace. I was intrigued, but silently not impressed.)

(2012)

This article can be summarised in one word: learning. I've noticed over the years that there seems to be a growing divide amongst programmers, between those who believe in learning, and those who don't (and actively try to avoid it); unfortunately the latter has become a majority position, but I still try to show others this article when they don't understand code that I've written and would rather I stoop to their level.

A look around the site at what else he has accomplished, should be enough evidence that he isn't just a charlatan, unlike some others who have made a consulting career out of spouting pompous hot air about methodology.

This whole "clever code" has become a social thing.

It's one of the things people say when they don't like some piece of code, but they also can't justify it with a more in-depth explanation on why the cleverness is unecessary/counter-productive/etc.

Truth is, we need "clever code". Lots of it. Your OS and browser are full of it, and they would suck even more without that. We also need people willing to work on things that are only possible with "clever code".

From this point of view, the idea of the Lever makes sense. The quote also works for criticizing clever code, as long as we follow up with concrete justification (not being abstract about some general god-given rule). In a world where _some clever code is always required_, it makes sense that this quote should work for both scenarios.

(2012)

> You effortlessly wield clever programming techniques today that would've baffled your younger self. (If not, then I'm afraid you stopped evolving as a programmer long ago.)

... Perhaps if we allow that "clever techniques" can yield simpler results than my former self did.

I am very happy and sad for people who will never debug their own code for days to figure out subtle bugs. Happy because they won't endure the torture, sad because an LLM took away their opportunity to learn and better themselves.

[dead]

This article says nothing of substance.

If debugging is 2 times harder than writing code we have at least two choices. One suggests to write simpler code. But another one means not debugging code at all, which may be achieved by using a programming language way better than C, which allows fixing (almost) all bugs in compilation time.