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

▲

jodrellblank 2 hours ago | parent [-]

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?

	▲	OkayPhysicist 2 hours ago \| parent \| next [-]
		"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.
	▲	PaulDavisThe1st 2 hours ago \| parent \| prev [-]
		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.