Some advice from the dark side from one who learned the hard way.
The requirements are unclear. Nobody has done an in depth analysis of
all the implications.
Don't do an estimate at this point. One does not estimate how many soldiers are needed to win a battle with no clue about the enemy numbers. The estimate is made after scouting. This is unless you already fought this enemy.
The new feature will probably break some assumptions you made in your
code and you start thinking immediately of all the things you might
have to refactor.
This is your responsibility to factor in unless you expect others to have the expertise about this area.
You have other things to do from past assignments and you will have to
come up with an estimate that takes that other work into account.
Same as above, even for unanticipated work that's created by a slob team mate next to you with a near non-existent test procedure which causes your code to glitch out that you can't perfectly predict in advance. It's a weather forecast.
The 'done' definition is probably unclear: When will it be done?
'Done' as in just finished coding it, or 'done' as in "the users are
Understand the user-end requirement here, think like a user. Don't do what your peers do if they estimate something to be "done" just because some basic functionality with a barebones workflow that no user can possibly tolerate is what they consider to be "done". Think of it from the user standpoint, because that's all the client you're making the estimate for will typically understand. Estimate towards the complete user-end requirements, not towards the barebone technical requirements. And realize that your clients asking for estimates will be totally inaccurate here about how they word things and understand the technical aspects of what you say.
No matter how conscious you are of all these things, sometimes your
"programmer's pride" makes you give/accept shorter times than you
originally suppose it might take. Specially when you feel the pressure
of deadlines and management expectations.
Don't do this! You sound like a self-motivated hard worker and possibly one who gives in easily to coercion.
The problem here is this: let's say you and Joe made time estimates for the same task (but between two separate employees, unaware of both estimates at one time). You estimate valiantly, "one week". It's okay you think, you'll work over 100+ hours a week, unpaid overtime. Now you're three days late.
Meanwhile, Joe estimates 5 months. You think this is ridiculous, you think you can pull this off in one week. How much does Joe work? 10 hours a week? ... except he finishes on time in exactly 5 months.
Guess who gets perceived as the jackass? That's right, you. Joe seems like a great worker, you seem unreliable now. It doesn't matter so much that you might have achieved an even better result in ~7% of the time that Joe took. What matters is that you were 3 days off from a one week estimate.
Never err on the side of the tighter estimate. Err on the side of the looser estimate. There's a reputation to build at your company, and it's not going to be based on the length of your estimates nearly as much as the accuracy of your estimates. It's easy to be accurate with an estimate that's too long, you just get more time to work on the problem and solve it better. An estimate that's too short leaves no breathing room at all, you either meet it desperately or you're screwed.