I chose this to be the second lesson because I feel this is one of the things I learned through experience. It’s the basis of many many other lessons.
So what does it mean to be paranoid about your code? While you’re writing code, for some strange reason, you have this false confidence that it will work. It’s false because it’s statistically impossible to write code that works the first time. Consequently, you have to assume that everything you write will fail.
Sometimes a failure is not bad – it depends on what you’re writing. If you’re implementing a word count feature for a document editor and your code causes the editor to crash, then there’s always auto-save that will give the user his latest changes minus the last 2 minutes or so. But if you’re writing the auto-save feature for that same document editor, your feature can ruin big, important documents that belong to clients who will never buy software from you again.
In practice, being paranoid about code means that you should check every return value from every function and exit error situations as gracefully as possible (the optimum being working in a transaction-like manner). Include sanity checks and assertions as much as you can, so that during tests your code will crash early instead of dragging an error to the point where it can’t be found.
Both advices, “crash early” and “anything can fail”, are well known in one form or another. Today they seem obvious to me, but I first read them in a book called “The Pragmatic Programmer”, which is a great read for developers at all levels.
