▲Kernighan's Lever (2012)(linusakesson.net)
39 points by tosh 2 days ago | 4 comments
▲mbivert 3 hours ago
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.

[0]: https://users.ece.utexas.edu/~adnan/pike.html

▲rob74 5 minutes ago
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 minds 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...
▲afandian 3 hours ago
This is a great piece.

> ... since you are confident that you understand how the code works, having written it yourself, you feel that you must be able to figure out what is going on. ... Suddenly you see it, and you're blinded by a bright light as all the pieces fall into place.

There's a particular frame of mind like 'I feel that there's a bug in this specific bit of code'. I often find that once I make that shift it's suddenly easy to see the bug. I have tried to cultivate this feeling, but it's not easy to suddenly conjure up. A bit like flow state.

▲mannykannot 56 minutes ago
It is a pedagogically useful exercise to spent some time trying to figure out what went wrong before firing up the debugger or writing new test cases. One approach is to try to identify the assumptions, and especially the tacit ones, that would have to be true for the code to work, and which might, if false, lead to the specific error observed.

While I think it is wise to heed the warning implicit in Kernighan's aphorism, the question it poses can be answered by noting that finding errors provides additional information, allowing you to debug it without first getting any more clever. What makes debugging harder than writing is that in the former, you are dealing with reality, not your simplified, incomplete and possibly tacit assumptions about it.

▲AnimalMuppet 16 minutes ago
I often think of it almost exactly backwards from that: "What it's doing should be impossible. So what precursor that I think is impossible would have to be possible for that to fail?" I often come up with two or three possibilities. And then: "How can I find out which one it is?" This often involves re-running it with enhanced logging.

And then repeat, with the new thing that should be impossible but is still happening, until I get to the root cause.

▲macintux 56 minutes ago
We frequently see what we expect to see. If I'm convinced something isn't in a certain location, I won't find it, digital or analog.
▲nicopappl 2 hours ago
It assumes that "Skill" is a 1d value. But the ability to write quality code and the ability to debug are a bit orthogonal.

Being better at debugging doesn't necessarily makes you better at writing less complex, more approachable code. Though debugging should teach you which patterns cause bugs or impede debugging.

And what do you do once you are so skilled your software doesn't have bugs? :P

Regarding self improvement, Aaron Swartz put it better here: https://web.archive.org/web/20240928215405/http://www.aarons... (tldr: do things you don't like)

▲ 2 days ago