I've worked at agencies for my entire career. Agencies are unique among software companies in their singular obsession with time. Time is their bread and butter, so they tend to pay a lot of attention to how long things take. You can go so far as to say that a service business is as profitable as their ability to accurately estimate their work. (Value pricing is for another post.)
As a programmer, estimating your work is good practice, even if your day-to-day doesn't requrie it. There are a few reasons why:
Time is important everywhere, even if not at the hour level. When your manager asks how long something will take you, being off by a day or week could have a substantial impact. Even if you work for yourself, understanding how long something will take will help you make important decisions about what to work on and when.
Estimating and tracking your time will help you become a better programmer by forcing you to think broadly about efficiency. This simple act can lead to valuable insights into how you work.
If I may be somewhat recurisive, estimating is learned by doing. There's no other way to do it. The more estimating you do, the better your estimates will be.
Unfortunately, most developers are terrible at estimating. I have identified four reasons for this:
Naivety: By far the most common reason, most developers simply haven't developed a skill for estimating. You can be an excellent programmer, but if you haven't put in your time to hone this skill, you probably suck at estimating.
Optimism: Developers tend to be an optimistic bunch, thinking things are much easier than they really are and glossing over important details when considering the effort of a specific task. While this is a loveable trait, it can be infuriating to those trying to plan around these optimistic estimates.
Fear: A developer may think that they'll be considered a poor developer if they estimate as much as they think the task might really take. On the flip side, they may be so scared of going over an estimate that they end up estimating way too high.
Hubris: An estimate of two hours for a task that will really take two days may be driven by one's exaggerated sense of coding prowess.
Put simply, estimating is a skill based on experience that must be learned and continually practiced. It's not hard at all, but it does take some consistent application of a rigorous process.
Here's how to establish a healthy estimating practice:
Whether you have to or not, estimate every programming task before you start.
Break up large tasks until you're working with estimates of hours. Over time you'll be able to be flexible on this depending on your comfort level estimating a given task.
Track your time with religious fervor. There are countless tools to help you do this as painlessly as possible. Despite them all, I still use a text file and a macro to insert timestamps. (I'll post my timesheet text file processing script here at some point).
When you're done, compare the actual vs. estimate. If they're substantially different, consider what you can learn from the exercise. Record your findings.
Recognize that most of estimating is properly understanding the requirements, or at least making intelligent (and documented) assumptions about them. Consider your client before assuming what they want is the simplest possible solution. Developers tend to assume their client wants a Yugo when the client really wants a Mercedes. Feasibility within budget generally falls somewhere in between. Your client needs you to help them make those decisions, which is why estimate accuracy is important.
Don't get cocky. Keep practicing estimating this way throughout your career. Everything changes, and so will your estimates.
Over time (and it does take a fair amount of time, so be patient), you'll get really good at estimating. Along the way, look for ways to abstract the effort of doing similar types of things. The more you do that, the less ultra-specific requirements and planning you'll need to come up with mostly accurate estimates. Keep it up and before you know it, you'll be an estimating master.