Our experiences obviously differ. Usually it goes like this - the developer gives his best estimate (which is, by the way, hard by itself - a lot of things has to be taken into account), and that estimate is considered too high. So the developer is ordered - in one form or another - to, effectively, "do it faster". Often it's by cutting corners in places deemed least important - but then it also reduces probability of the correct estimate overall. One more thing - specifications are quite rarely are good enough - there are other reasons why that's the case - and the final result causes management to wonder, why it doesn't include this, of why that works this clumsy way. So nobody's happy - and developer pays the price. It may look as the developer isn't good at writing software... because "writing software" is a sort of encompassing figure.
That's not bad estimating though. That's psychopathic management. The developer gives an estimate which is "too long" for the manager, who responds by essentially ignoring the estimate and laying down arbitrary deadlines. Surprise, surprise the arbitrary deadlines are missed, and the psychopathic manager blames the developer.
The developer's ability to estimate accurately is not an significant factor in this scenario.
