An assumption: code is designed [to get things done]. Another assumption: the [thing to get done] will likely eventually be transformed via evolution or destro

An assumption: code is designed [to get things done]. Another assumption: the [thing to get done] will likely eventually be transformed via evolution or destroyed, as all natural things like rocks and species and hydrogen atoms and gluons and the entire known universe starting[?] with the big bang transforms via evolution or gets destroyed. A conclusion: code that can not be easily changed and evolved will be conveniently destroyed via a complete re-write. This is why "facades" and opaque APIs are so popular - it is theoretically possible to rewrite different components of the code without rewriting the whole entire dang thing. Case in point: http://stackoverflow.com/questions/810129/how-does-whiles-t-work http://stackoverflow.com/questions/810129/how-does-whiles-t-... >>>while (s++ = t++); This is code that is hard to understand(hence the stackoverflow question), making it not easily changed. Not a good sign for the survivability of the code. JoelonSoftware.com makes a sparse point with this example, in that a "good" coder must understand what this does. He leaves the reasoning up to the reader, likely because he is clever enough not to make any claims that can be disagreed with. Luckily I am not this clever and I will make a claim that follows from my assumptions and conclusion above: Claim: a "good" coder needs to understand the above type of obfuscated code so that they can evolve it or destroy it safely when they see it. Note that my claim does not say whether a "good" coder would write code like that. A "good" coder gets the job done, whether it's a write-once-use-once-read-never perl one-liner or a big part of a big program. I only claim that a "good" coder must be able to read it, so that they can change it or destroy it safely.