Some posts in the Borland newsgroups have got me thinking about what a professional programmer's responsibility is when a bug occurs in code that is not theirs. The result is this list of guidelines and principles. The main thrust of this list assumes that a programmer is a technical person by nature. They do not need to be coddled and led by the hand.

• Most bugs that are perceived to be bugs in a vendor's codebase, are usually not the vendor's fault. The first Maxim of Debugging is: The bug is most likely in your code.
• Make the effort to work with the vendor of the bug to provide a clear, minimized, reproducible test case that demonstrates the bug. Expecting the vendor to fix a bug that they don't know about is just silly. If the bug is important to you, report it in a thorough manner.
• If the bug is a true show-stopper (a term that is much over-used, in my opinion), then find a work-around. There are always other ways to express what a program should do. Rarely is a bug so serious that you can - in good faith - throw your hands up in the air and claim defeat. A professional programmer looks at this as an opportunity to distinguish themselves. If you code the work-around in a non-intrusive way, you can remove it easily when the vendor does fix the problem.
• If you have source code for the library, debug it. It will help you understand exactly what the bug is, and hopefully, help you down the road by preventing you from making the same mistake. This can also help in bug reporting and finding a work around.
• If you don't have source code, you can still make assumptions about what part of the black box isn't working and write a test case to prove that. If your assumptions are wrong, modify the test case.

While bugs are an inevitable fact of life, it's how you deal with them that truly defines what kind of programmer you are. Everyone has deadlines, but taking time out of your schedule to work with your vendors to resolve problems is part of your responsibility as a professional programmer.