[DanielBMarkham]

This might be a good time to remind folks of Markham's Rule of Technical Debt: The economic cost of making your code better can never exceed the economic value of the code to begin with.

Write a function that saves to disk but never checks if it fails? Who cares? If you never use it again, or it never does anything of value to anybody, it's not worth anything.

Craftsmanship is a great thing, but it always exists inside a larger economic context. The guy laying tile in your kitchen doesn't give the same attention to detail as the artisans completing the Sistine Chapel. And this is a good thing! He might not have much education, he buys pre-assembled pieces, and he's liable to just slop it in there. This is appropriate because your bathroom's economic value is miniscule compared to a great cathedral. Likewise, if you're in a startup writing code, you've only got a 1-in-10 chance or so of your code ever having any value at all beyond just playing around. Completely different picture if you're being funded by BigCorp to write version 8 of the Bells-And-Whistles App. Yet some of us insist on treating all this coding the same.

So I am a bit annoyed at the use of the word "faith" in this context. If "faith" is calling functions and expecting them to either execute or terminate the program, CS is replete with faith-based-coding. This entry describes the situation too much in loaded terms.