"Understanding what code is doing" is a unitary skill (even if it has many different aspects to it, along with language and task specific details). There are plenty of people who are good (enough) at writing new code to do a task but do not understand how to debug; there is (I would suggest) nobody who is good at debugging code who is not also good at writing it.

If debugging is not a separate skill then there is either:

- the author wrote it (including 'debugging') until it worked properly. Therefore they were clever enough to write it that way.

- the author can't make it work (including 'debugging') and therefore they aren't clever enough to write it that way.

And there cannot be a state where they (are clever enough to write it but it doesn't work properly) and they (are not clever enough to debug it), because the fact that it doesn't work properly and they can't make it work properly refutes the claim that they were clever enough to write it that way, and it becomes the second state above. Which puts you on the side of what I'm saying?

"Works" is a less absolute term than you treat it as. If I'm hacking together a little automation script, if the pretty path gives the correct answer, then it "works" to some degree. If that script graduates to part of a company workflow, I'd probably need to fix up some of the corner cases. Like if I wrote it to take in tab-delimited CSV files, but it breaks horribly when encountering a comma-delimited CSV file, I should probably realize that and either guard against it, or add a fix to handle it appropriately.

Are you suggesting that if you wrote your CSV file parser as complex as you could manage, then it would be twice as hard to change the comma to a tab, and you wouldn't be able to do that? That's in line with the quote I'm questioning which you are defending. I might think that the corner cases were easier and less complex than the core.

I'd read the quote as saying "if you write a compression algorithm with the most obfuscated 'clever' macro-using compiler-quirk exploiting C code you can manage and it doesn't work properly, you won't have enough brain power left over to debug such code and make it work. Instead you should have written it with idiomatic C and boring for(){} loops and then you would have a better chance of debugging it until it works". I was questioning the quote and suggesting that if debugging is a separate skill, it must be one that can be developed and improved by practise and tooling.

The person above me suggested that coding and debugging are not separate skills, which rather throws the quote into confusion - if you can "write" it but it doesn't work, and you can't debug it, and "debugging" is the same skill, what are we talking about at all?

This seems to assume that debugging is required to get software to work properly. Sometimes that's true, sometimes it isn't.

And even when it is, sometimes the "not working properly, must debug" point occurs later in time (sometimes much later) from the "it appears to be working" point.

And I might say that the more clever (skilled, experienced, wise) a programmer is, the more likely they can write something 'clever' and make it work and not need to debug it. Then why should they follow Kernighan's quote to avoid working that way?

As I take the quote, it would have been about 1970's, 1980's C and would not have had the benefit of an IDE with "edit and continue" or a LISP or Prolog or Smalltalk interactive REPL with live edit and retry, or ELM's "time travelling debugger" or Git and all related tooling for tracking down changes and who made them, or more modern fuzzers and Valgrinds and static analyzers.

Making a case for writing non-surprising idiomatic code is one thing, but HN parroting the "debugging is twice as hard as coding" and downvoting someone who asks for evidence for this claim is cargo-culting. Why would it be twice as hard and not 1.2x as hard or the same hardness or 10x or 100x as hard? And why would the relationship be fixed, even if tooling and languages and the industry change? And what does it mean to say you can write a, say, compression algorithm "as cleverly as you can" but it's twice as hard as that to spot that you typoed a variable name or something?

The evidence is that many respected people with decades of experience generally agree with them. They are not scientific theories that require validating through testing, they are general advice that is usually true and good to keep in mind.