An addendum to that: Design your error messages. When dealing with exceptions, catch/wrap the exception (e.g. using InnerException in .NET) and add important in

An addendum to that: Design your error messages. When dealing with exceptions, catch/wrap the exception (e.g. using InnerException in .NET) and add important information if necessary. You'll be glad you did six months down the line, when the exception actually pops up and you instantly know how to reproduce the bug (perhaps because you know the id of the business object involved). Edit: Also, use understandable text for error messages. Don't go around talking about threads/sockets etc. unless they happen on that abstraction level. The user should see business-level errors, so they know what happened in the business domain and why ("we don't know why, this shouldn't have happened" is a reasonable answer there, too). Edit 2: I just thought of Git's "plumbing vs porcelain" metaphor. Abusing it slightly: It's much more pleasant to be notified of an error by a red light instead of standing ankle-deep in sewage. I guess that metaphor breaks down a bit, since toilets more often have the latter than the first :)