In the corporate world it's hard to get any significant work assigned to you unless you can arrive at the correct mix of accurate and acceptable estimations.
The method that works best for estimating depends to a great extent on the size and scope of what you are developing. Not that surprisingly the magnitude of error in your estimation also increases in parallel to the size of the project. Small projects such as one shot utility programs are best estimated by your gut feeling from experience. Such tasks rarely last more than a couple of man days.
Adding a bit of functionality to an existing system can be adequately estimated by breaking the project into component estimates. Say one day for database design, a day for user interface, a day for testing, tweaking, and modifications. More or less depending on your development environment.
If you are fortunate enough to be developing a middle sized complete system from scratch, then you can use a standard project management tool, fill out tasks and estimates, then resource leveling, addition of slack, and then add an additional 15% for each resource assigned to the project.
Somewhat counter intuitively estimation for exceedingly large projects works better if you don't go through the effort of summing up the cost of individual component tasks. Very large projects are dominated by the costs associated with inter personal and inter system communication, plus the overhead of change control. For that reason a tool based on the well researched interplay of these factors, such as Cocomo, gives the best results.
Estimation is an art that you develop mostly from experience. Remember to use the method that is appropriate for the overall size of your project.