Please don't hate me here, but I've spent much of my career in software engineering management, and as such I've also spent a lot of time gathering estimates from engineers about what they were working on. This was all part of an effort to help keep projects on track and to prioritize the features we would implement in the next product revision.
Although these "estimates" were somewhat useful, there was a huge variability in the accuracy of those estimates -- even when the estimates were coming from very skilled and experienced developers. In fact, if I had to guess, I'd say they were incorrect more often than not, and usually incorrect in the "wrong" way, where the tasks took a lot longer to implement than the developer had originally expected.
To this day, I've still felt like there must be a better way to estimate and manage the scope of individual programming tasks. This statement from Basecamp's Ryan Singer in his guide to the Shape Up development process really hit home:
Say you have two tasks, both estimated to take four hours. If one task is something the team has done ten times in the past, you can be confident in the estimate. Suppose the other task is something the team has never done before, or it has unclear interdependencies. It could take the four hours if all goes perfectly, but due to the unknowns in it, it could stretch out to two to three days. It’s not meaningful to write “4 hours, or maybe 3 days” as the estimate.
If these sorts of things interest you, I'd encourage you to check out Ryan's thoughts, as well as the rather simple tool they finally settled on at Basecamp to help give better visibility into how much effort is remaining for current programming tasks.
I've often felt that estimating the work left to be done was sort of a necessary evil, but using something like this to not only keep track of the amount of work left to do, but also the kind of work left to do, may actually prove useful.