Comment by OkayPhysicist
21 days ago
"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?