Comment Re:Tech time lines (Score 1) 179
The first key is knowing what you actually have to do, and knowing what else will be competing for your time. So let's say you estimate a component will take 8 hours of programming to do. Well don't assume that it will be done in a day. You have some break time in there, emails to answer, possibly a meeting, so 8 hours of work will likely take you closer to 11 or 12 to actually accomplish.
After that - just keep guessing by writing stuff down and comparing actuals with estimates. My rule of thumb for myself is take how long I think I could do the project in, assuming nothing comes up to block it. Now double it. And add an extra half of the original estimate. That is usually in-line with the final product for me, but that does assume nothing else comes up.