Alway give extremely verbose error information

When programs encounter errors, they should always make available detailed information about what actually went wrong. If it's too verbose, or too technical for the expected audience, it should still be made available; either behind a "Details" button, or written in a log file.

An anti-example is the when the awesome tool, ReSharper, runs an NUnit test, it can first automatically build any changed projects. (Nice.) But when that build fails, it says "Build failed". That's it. No output in the build output or errors windows. No nothing.

(I found this nice blog post explaining what the problem was.)

A corollary of this philosophy is that when catching an exception and throwing a different exception, you should always nest/wrap/chain the caught exception as the inner exception of the new one. The outer exception might repeat information from the inner exception; include the inner exception anyway. The inner exception may be verbose, confusing, etc.; include it anyway.

(The only, rare "exception" to this rule is when the inner exception reveals sensitive information -- credentials, HIPPA info, etc. This is usually code running on a server, in which case the inner exception should instead be logged into a secure log file for possible later problem analysis.)

Outlook does not include Deleted Items in Instant Search by default

Outlook's Instant Search doesn't include Deleted Items in the search results by default.

You can change this by enabling the corresponding checkbox in the Search Options dialog.

See this article, the section titled "INCLUDE THE DELETED ITEMS IN INSTANT SEARCH".

In Outlook 2010, the dialog looks like this: