I was re-reading The Art of Unix Programming and re-discovered some great ideas. Sharing with you: Rule of Modularity Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable. Rule of Clarity

Discussion at: https://www.facebook.com/groups/programming.philosophy/permalink/879945482055839/ I've been dealing with the consequences of defects this week. Frustrated, I went back to the Holy Bible (aka Extreme Programming Explained) for some guidance. I rediscovered this section in the Corollary Practices: Root-Cause Analysis Every time a defect is found after development, eliminate the defect and its cause. The goal is not just that this one defect won't ever recur, but that the team will never make the same kind of mistake again.

From A Discipline of Programming by Edsger W. Dijkstra: (Up to this very day there is among the more theoretically inclined computing scientists still a widespread feeling that recursive programs "come more naturally" than repetitive ones.) For the alternative way out, viz. providing the couple "repetition" and "assignment to a variable" with a sound and workable mathematical basis, we had to wait another ten years. The outcome, as is demonstrated in this monograph, has been that the semantics of a repetitive construct can be defined in terms of a recurrence relation between predicates, whereas the semantic definition of general recursion requires a recurrence relation between predicate transformers.

Donald Knuth speaking in an interview, from The Essential Knuth by Edgar G. Daylight: It is very easy to become enamored of logical consequences without being enamored of efficiency. Once you get bitten by this bug, you can see all kinds of beautiful possibilities that are intellectually satisfying but economically tragic. Of course not all abstract things are bad. It's fun to solve puzzles, so you look for new puzzles to solve.

Gerald J Sussman, from the Forward to The Little LISPer: In 1967 I took an introductory course in photography. Most of the students (including me) came into that course hoping to learn how to be creative–to take pictures like the ones I admired by artists such as Edward Weston. On the first day the teacher patiently explained the long list of technical skills that he was going to teach us during the term.