The first phase for a good estimate is to breakdown the problem at hand to smaller pieces. Try breaking down the task at hand to functional pieces. Since you're a programmer, break down your work to the development phases you're expected to follow (research, design, test planning, coding, testing, code reviewing, documenting, etc.).

A good detail to level to strive for is having tasks of around 1 day of effort in size.

When you're done with the breakdown, the second phase would be to estimate the various tasks you have. Factors that could affect your estimates are:

1. The level of certainty/uncertainty around what needs to be done.
2. The technology you're working with - how much overhead do you have in a coding to testing iteration? How long does a build take? How hard is it to test and verify your code in small iterations?
3. How much interaction do you need with other developers to accomplish your tasks?
4. How stable is your environment and setup? Do you have lots of breakages or outages on a daily basis, that could block you from making progress?

I could go on and on... Try thinking of such criteria that are applicable to your environment. Take these points into account and try adjusting your estimations according to the answers to those questions. There's no one answer or a lookup table to help you pick an estimate given answers to those questions.

The next phase would be to review your estimates with your experienced peers. Don't just review the numbers. Review the rationale behind picking the numbers as your estimates.

Now, the final note here is to practice and monitor yourself over time. Keep a log of your estimates and the parameters that made you pick your estimates, log how much time did the tasks really take you and why. What factors had impact on the actuals? Do a retrospective with yourself from time to time and try to find factors you can take into account the next time you need to provide estimates.

Practice makes perfect (although there's no perfect in effort estimations...).

The first phase for a good estimate is to breakdown the problem at hand to smaller pieces. Try breaking down the task at hand to functional pieces. Since you're a programmer, break down your work to the development phases you're expected to follow (research, design, test planning, coding, testing, code reviewing, documenting, etc.).

A good detail level to strive for is having tasks of around 1 day of effort in size.

When you're done with the breakdown, the second phase would be to estimate the various tasks you have. Factors that could affect your estimates are:

1. The level of certainty/uncertainty around what needs to be done.
2. The technology you're working with - how much overhead do you have in a coding to testing iteration? How long does a build take? How hard is it to test and verify your code in small iterations?
3. How much interaction do you need with other developers to accomplish your tasks?
4. How stable is your environment and setup? Do you have lots of breakages or outages on a daily basis, that could block you from making progress?

I could go on and on... Try thinking of such criteria that are applicable to your environment. Take these points into account and try adjusting your estimations according to the answers to those questions. There's no one answer or a lookup table to help you pick an estimate given answers to those questions.

The next phase would be to review your estimates with your experienced peers. Don't just review the numbers. Review the rationale behind picking the numbers as your estimates.

Now, the final note here is to practice and monitor yourself over time. Keep a log of your estimates and the parameters that made you pick your estimates, log how much time did the tasks really take you and why. What factors had impact on the actuals? Do a retrospective with yourself from time to time and try to find factors you can take into account the next time you need to provide estimates.

Practice makes perfect (although there's no perfect in effort estimations...).