Why your first estimate is wrong
People are consistently optimistic about how long their own work will take. Buehler, Griffin and Ross reported this in 1994 with students predicting when they would finish their thesis. Most missed their own predicted date, and the average completion time was well past it. The striking part was that even the students asked for a worst case estimate, the date by which they would finish if everything went badly, tended to overshoot that too. The bias survives being warned about it, which is why a buffer applied mechanically works better than trying harder to be realistic.
The bias is specific in an interesting way. The same people are reasonably accurate when predicting how long someone else will take, because they judge from experience of similar work rather than from a mental picture of the plan going smoothly. Your own project comes with a story attached, and the story rarely includes the day you spend on a bug that turns out to be a config file.
Estimate from history, not from the plan
Kahneman and Lovallo named these two ways of looking at a project the inside view and the outside view. The inside view builds up from the details of this project. The outside view asks how long comparable past work actually took and starts from that number. Bent Flyvbjerg developed the same idea into reference class forecasting for large infrastructure projects, where the method is to find a class of similar completed projects, look at the real distribution of their overruns, and adjust your estimate to sit inside it.
You can do a small version of this without any data science. Think of the last three projects you finished that were roughly this size. Write down what you originally thought each would take and what it actually took. The ratio between those two numbers is your personal buffer, and it is usually a more honest input than anything you can reason your way to.
Unpacking the work helps
Kruger and Evans found that asking people to break a task into its component parts before estimating reduced how badly they underestimated it. Listing the steps surfaces the ones you would otherwise have skipped over, and the total of the parts comes out higher than the guess for the whole. This is why the tool above takes a list rather than a single number. If your list has three lines on it, it is probably not finished.
Unpacking is not a cure. The parts themselves are still estimated optimistically, and very fine-grained lists start to add their own overhead. It works best as a first pass that finds the missing work, with the buffer still applied on top of the improved total.
Deadlines from outside beat deadlines from yourself
Ariely and Wertenbroch ran a study in 2002 where students faced either evenly spaced deadlines set by the instructor, deadlines they chose for themselves, or a single deadline at the end of term. The externally imposed spaced deadlines produced the best performance. Self-imposed deadlines helped compared with having none, but people did not space them well, and left too much until the end.
The practical reading is that a date you tell someone else about is worth more than a date in your own notes, and several checkpoints along the way are worth more than one date at the end. If your project has no external deadline, make one by promising a milestone to somebody who will notice.