Ask how long roughly similar projects in the past have taken. Do not do any specific thinking about the detailed implementation. I'm serious!
It also helps if your development cycles are fairly short (i.e. 1-2 weeks and no longer). I have found that it is much easier to estimate how long it will take if the amount of work you are estimating is smaller.
Keeping your development cycles short also has the beneficial side effect of reducing the shock factor when you have to double it.
Unless you're doing fairly repetitive work (cranking out brochure websites for clients, for instance), you shouldn't be doing any "roughly similar" projects! Each thing you do should be brand new—if it wasn't, you'd just reuse the code you already have.
That is the perennial dilemma in software estimation. You don't know how big it is until you're halfway done building it.
I'm not proposing a solution to this problem, just pointing out that this IS a problem, and probably not one that can be solved in a one-line bit of advice. Saying "cut it up into pieces" or "estimate similar past projects" is like telling a nervous guy to "just be himself" on a first date.