Explaining rubber duck debugging
Rubber duck debugging is the process of explaining your problem out loud to a suitable object (a rubber ducky or another person, take your pick); the alternate version is to write down your problem, for example in a grumbling blog entry or an email. This may sound very peculiar if you've never done it, but it works surprisingly well.
(Obligatory attribution dammit to the Centresource.com blog entry on it.)
As it happens, my leading explanation for why this works so well has already been written up here, so I will just quote it:
[...] Because speaking out loud forces you to marshal your thoughts, which in turn highlights any contradictions or missed steps that you hadn't noticed while everything was just swirling around inside your head.
My experience is that it's very easy to handwave things and lie to yourself in your thoughts, partly because we allow a kind of mental shorthand that lets fuzz sneak in. When we speak out loud or write something down there is no such shorthand and it is much easier to see that we have (or haven't) covered something.
The other useful thing that rubber duck debugging can do is expose just how ugly and stupid a particular idea or bit of code or interface is. This followup of the original message has a nice story of it in action.
Several times I've started to document a bad idea, realized how embarrassed I would be to have people reading about it, and been driven to fix it. It's especially useful for stupid limitations or awkward system administration rain dances. (This does require you to have a sense of shame or a pride in your work, but I hope you have that already.)