Kernighan's Law:
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
back
3 comments
I'm finding LLMs invaluable in deciphering this kind of thing, with suitable prompting:
System: Always provide clear instructions from the perspective of an expert in the field. Double-check answers for logical coherence and factual correctness, using a consistent step-by-step methodology. Explain the benefits and disadvantages of different approaches in a compare-and-contrast style, and value security, readability, and organization over clever tricks.
User: Consider the following code function in Python: "def minimumTotal(self, t): return reduce (lambda a,b:[f + min (d,e) for d,e,f in zip(a, a[[1:],b)], t[::-1])[0]" . The goal is to rewrite this using only simple python bulitins like for loops. Use a step-by-step approach to dissassemble this code into a simpler format, and include plenty of comments.
User: Clarify what is meant, mathematically, by "the minimum path sum from top to bottom in a triangle"
Okay now I understand it... This is much easier if the original code has a set of robust tests you can run your LLM-generated code against, to make sure it works as advertised, but you can get the LLM to generate tests too if needed.
Now I want to go see how it does when faced with C obfuscation competitions.
Unless you got dumber between writing and debugging, it more likely means that it takes twice as long (or even more if you haven't touched it in a bit). It's unlikely that Kernighan meant it takes someone twice as smart to figure out what you were doing as that would be a nonsensical interpretation (someone twice as smart may not be able to figure out what the stupid person is trying to do in the first place if the code written was nonsensical).
> It's unlikely that Kernighan meant it takes someone twice as smart to figure out what you were doing
no, that is exactly what he meant. clever code means you are just barely able to understand it enough to write it yourself [in any amount of time]. therefore, you aren't going to be able to debug it at all, by a factor of nearly two. and if you are the "smartest" person in the org (which he often was), then you are really in big trouble.
now obviously things in the real world like "smart" and "clever" are not one-dimensional quantities in neat categories, but he was making a memorable and funny quote, with quite a bit of truth to it, not a precise scientific hypothesis.
see also: "too smart for one's own good"
> nonsensical interpretation
how so?
> someone twice as smart may not be able to figure out what the stupid person is trying to do in the first place if the code written was nonsensical.
true, but irrelevant, this is about clever code from a smart person, not nonsense code from a stupid one.
The Linux kernel for example is filled with code that is at the limit of cleverness of the people who came up with it (e.g. RCU or intrusive linked lists). Turns out that once a concept is introduced, people can absorb it and become smarter. It’s just simply categorically not true that something written at the limit of your cleverness at one time prevents you from being able to debug it because cleverness is not something fixed and static.
agree, but as i said: "he was making a memorable and funny quote, with quite a bit of truth to it, not a precise scientific hypothesis"
never-the-less there is still a lot of truth to the saying, nobody said it was universally categorically true.
i've written clever code when it needs to be clever, for example performance. along the lines of the RCU code. when i do i plan for handling the complexity - static analysis or exhaustive testing if possible.
suddenly needing to advance your cleverness by 2x isn't impossible, but it's not fun if your butt is on the line.
Sure. I wasn’t advocating for making all your code clever. But clearly super clever code doesn’t make code magically not debuggable. It may not be fun to touch but usually you just make sure it’s well tested, documented, & then you try to never touch it again.
Most of the problems I've had to debug the place to look is not clear. Sure I've had to fix "The is not spelled Teh", but most problems are it breaks in some weird situation - step one is figuring out where to even start looking. Once I narrow down the exact place to look it might be easy, but I have to hold a lot of different areas of code in my head while narrowing things down. Even when I narrow it down, sometimes the answer is make the code more complex, and if the code is already on the edge of how complex I can handle I won't know how to make it more complex.
not smart enough to debug it in the same amount of time it took to write it