Tracing is more effective than debugging when time itself is a factor: concurrent processes, event-based systems.
Rubber ducking: try to explain what the program is supposed to do out loud. By having to verbalise your assumptions, you may suddenly gain a new insight into a problem.
First, explore theories that your code doesn't use the library correctly, than that the library itself is broken. "Select is not broken."
"If it took a long time fixing a bug, ask yourself why. Is there anything you could do to make fixing such bugs easier next time? (Constantly think about what you are doing)
‣