"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do."
-- unsure; often attributed without source to information philosopher Ted Nelson
A good development environment includes debugging tools such as a symbolic debugger. Personally, I never use them, but you should. :-)
For every subroutine call whose failure could be significant, check the return value for error conditions. If the call supplies an error message (for example, as a system error number, or via a library error message facility), include that message in the program's error reporting.
(to do: give examples for perror, etc.)
Error messages should be as specific and descriptive as possible regarding the source of the error.
Every software package should provide methods for reporting bugs in the software and its documentation.
When a new version is released, if there are any known bugs that haven't been fixed, list them in a "Known Bugs" section in the appropriate documentation (User's Guide or Developer's Guide if there is one, and/or the README).
Every program should provide a method for reporting bugs. This may be as simple as printing "Report bugs to email-address" at the end of the "--help" message. This should be included in other documentation as appropriate (User's Guide, Developer's Guide, etc.).
The most important security consideration in debugging is to address bug reports quickly, as some bugs can be exploited as security holes. Any security-related fixes should also be logged in the ChangeLog file and the plain-text NEWS file in the package's top-level directory.