- I call this mechanism Kernighan's lever. By putting in a small amount of motivation towards the short-term goal of implementing some functionality, you suddenly end up with a much larger amount of motivation towards a long term investment in your own personal growth as a programmer.
Something he doesn't address: how will new devs read your clever code?
His cycle: I write code as clever as I can. Then, when it breaks, I'm forced to become more clever to fix it. GoTo 1. I get that. But I have seven years' experience. How does a fresh undergrad understand my clever code, much less debug it?
Part of the answer is that great code isn't clever, or that great code, despite being clever, is still elegantly simple to understand.
But it isn't that simple. The value of cleverness is when it fixes something bad. For example, sometimes it's impossible to avoid duplicate code without metaprogramming. Is duplicate code less bad than the cleverness of metaprogramming? I find that hard to believe. Then where does that leave the freshman dev?
I think the appropriate thing is to write the program as a whole cleverly, and to make each portion understandable, either through detailed commenting, or by making the code (and naming!) easily interpretable. Cleverly doesn't necessarily mean inscrutable, as briandmyers pointed out. I believe people mean several different things when they talk about clever code: 1. Written with the best abstractions to avoid duplication of code and make future extension easy 2. Optimized for efficiency 3. Optimized for size 4. Written in an "interesting", complex way When most people hear this quote, I suspect they immediately think of the 4th definition and conclude that code should be written in a straightforward, stupid fashion. In this article, though, I think the author is emphasizing us to concentrate on the first three situations. For example, if you're implementing a file system today, you need to be clever about it. You could go and create something like a straightforward S5FS, but unless you start taking into consideration how the physical disk works and the best ways to place your blocks, you're not going to get good performance. The same goes for many other applications: anything crypto requires cleverness and intelligence; anything related to performance requires a deep understanding of the problem and its contexts. Also, the clever solution isn't always the complex solution. Compare Raft and Paxos, two protocols for distributed consensus: Raft is very straightforward, clever, and easily (compared to Paxos) implementable. Paxos, on the other hand, is a beast unto itself. I think the key issue when this quote comes up is people interpret the word clever as solely meaning accomplishing the same thing as the straightforward solution in a way that requires a lot of thinking. But sometimes this is done because fully solving the problem actually requires some hard thinking. And this is the key part: does your problem actually require much intelligence? Is it of a large enough size that you need to be that concerned about performance? For most people and most problems, I suspect that the answer is no. But this doesn't mean you shouldn't think about it first. After all, sometimes the clever solution is the better solution, when the clever solution makes your life easier.
It's not cleverness that's the problem, it's inscrutability. They can be linked but they are not the same.
Write your code so that it's as easy as possible for a later coder to read and understand - because that coder might well be you.
The best you can do is write some prose explaining how it works, and what you're trying to do, I suppose. Writing good comments is the hardest part sometimes.
That's essentially my conclusion, as well. I think it's important to ask the question though, lest we write inscrutable cleverness unnecessarily. I've also come to the conclusion that almost the only valid reasons are performance (where it's actually necessary; it usually isn't), and duplicate code.
And sometimes you just have to write "This works, so please don't change it unless you really know what you're doing". A heads-up is better than nothing.