Help me understand this Brian Kernighan quote

Question

"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." --Brian Kernighan

It seems to be a subjective question, but in your opinion,

'What exactly is he intending "clever" to be?'

Answer 1

"Clever" in this case means pushing a boundary of some kind - your hardware, your software environment, or your own understanding.

If you can only just reach this bleeding edge when creating the code, you will struggle going beyond the edge to debug it

Answer 2

If you push the technology the code is using to the brink of what you understand, you don't actually understand it well enough to write or attempt the testing practices that would be best to have for that same code.

Answer 3

If the code is complex enough to be at the limits of your skills, then debugging that code will exceed your skills. In other words, don't make code so complex that you can't maintain it.

edit

I just ran into another quote from Kernighan (and Plauger, in "The Elements of Programming Style"), which I think helps clarify the first:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Answer 4

You write code that is right on the bleeding edge of your ability to understand it. But when you come to debug it, you neeed even more understanding, which you haven't got.

The "cleverness" could be technology, data structures, algorithms - anything that you only just understand. Probably all three in my case.

Answer 5

It's simple math, yes? Let's say you're writing a application named "Thingy".

X = how smart you are.
S(WriteThingy) = how smart you need to be to write the code for Thingy.
S(DebugThingy) = how smart you need to be to debug the code for Thingy.

Debugging is twice as hard as writing the code in the first place.

So we get:

S(WriteThingy) = 2 * S(DebugThingy)

Given that:

if you write the code as cleverly as possible

We have:

X = S(WriteThingy)

Which basically means that you are no smarter than being able to write Thingy.

And since:

S(WriteThingy) < 2 * S(WriteThingy)

We get:

X = S(WriteThingy) < 2 * S(WriteThingy) = S(DebugThingy)

Or:

X < S(DebugThingy)

Which is basically what he said:

you are, by definition, not smart enough to debug it.

Answer 6

IMHO,
usually when we go back to modify old code (2-3 months old) we try to understand (remember) how it's working. Now, if we've made the mistake to over-optimize or overenginnered it, we'll have really hard time modifying it.

Answer 7

It simply means adhere to KISS principal. If you are spewing spaghetti of code or weaving architecture like undergrowth of a rain forest then you will choked at it or be lost into it very soon when you try to debug it.

Answer 8

It means you aren't as clever as you think you are! And, the sooner you accept that the sooner you can start writing "good" code.

Answer 9

Steven Sudit’s answer is right but changes the emphasis by reversing the statement. Kernighan opens with “Debugging is twice as hard as writing the code in the first place.” That’s the important bit. When you write the code you know, rightly or wrongly, what you’re trying to achieve; when you debug you don’t know why it doesn’t work. Once you accept that debugging is harder than coding then it follows that if you’re coding at the limit of your knowledge then you’re not equipped to be able to debug that code.

Answer 10

I like Nir's rephrasing "Understanding is twice as hard..."ref