I had a programmer working for me who would come in occasionally and report that he'd found a bug in the database library we'd purchased for our application development project. Being new as a team leader and having always believed for my own individual work that a "help desk" was really just a nice way to spend some time on the phone with a stranger instead of working on my project, I was unprepared for the sinkhole I stepped in next.

I took Enoch at his word and called the library vendor to report the problem. Of course they asked me to supply a small section of code the demonstrated the bug. They didn't want to see my whole application, just a tiny program that demonstrated the bug. No help from my telephone call, but their request seemed a reasonable one to me.

So I had Enoch work up such a program to submit to the vendor. He never came back with that little program, and when I questioned him a couple of days later, he told me that he'd discovered that there wasn't a bug in the library after all. Come to think of it, my phone call with the vendor wasn't really a "no help at all" call. I learned a lesson that I've passed on to students for years now. 19 out of 20 "bugs in the library" are really bugs in the client code. Or they result from a misunderstanding about how to use the library.

So I tell people to test new functions in a small demo program before using them in the full-scale application. And if there is a bug that needs to be reported to a vendor, then create a very bare demonstration program to illustrate the misbehavior. The vendor will ask you for this anyway, so you have to do it sooner or later. And many times your demo program will uncover the misconception that is keeping your project from working.

...All the world looks like -well- all the world, when your hammer is Perl.
---v