A rubber duck is the strongest tool in a programmer's debugging arsenal.
It's a killer desk accessory, a surefire way to test the safety of nearby water, and - most importantly - the quickest way to get to the heart of a problem.
Even if you've never heard of the term, it's likely that you've used rubber duck debugging before. Although the concept was first popularized in the book The Pragmatic Programmer, it's been around for as long as programming itself, and it's quickly become my favorite way to tackle a bug or a logic problem.
The idea behind it it simple. Whenever you run into a problem with your code, take a moment to stop and explain what you're trying to to do a rubber duck.
It doesn't have to be a physical rubber duck, although the ability to test the safety of any nearby water is a pretty great bonus. In this case a rubber duck can refer to anything - your coffee cup, the wall, or even a poor unsuspecting coworker. The key here is that whatever you're using, it must be inanimate.
Or, if you're using a coworker, at least willing to pretend.
It might sound weird, but the logic behind it is sound. It's a well known phenomenon that people will often miss mistakes in their own work, and that goes doubly for programming! Whether it's a missing semicolon or a mistaken leap in logic, you often won't see what's going on until someone else points it out to you.
Luckily, you can shortcut that by grabbing a rubber duck and walking it through your code. Usually even just the simple act of stepping back and trying to explain what you're doing will help you see what's actually going on, and you'll walk away with either a solution or a good idea of what steps you have to take next.
So the next time the console or the inspector lets you down, before you rage into the silent, uncaring void, grab a duck.