As experienced developers, how do you do time estimation in spite of things being stuck and new, unexpected, stuff coming at you with no extra time? This has happened to me and it's depressing and frustrating to have to ask for an extension again and again. Plus, the code and tests for it get boring.

I evaluate if I can do it in 5 minutes /hour/day/two weeks, then multiply by two or three.
Also there is this factor of knowing what is to be done, so if it's not known, makes all the estimates meaningless. It's worth to tell this upfront.
Third factor to consider is the independence. If your dependent on someone, multiply the estimate. Or explicitly say that there is this dependence.

If you work for a client with no real plan, it's very difficult. I used to make websites that way and it went badly ;) now I work for a large company, we use scrum as planning/working methodology and use planning poker to do estimates (to estimate effort, not time). That's whole new experience.

@cst1992 No magic bullet, development experience is required to be able to estimate even reasonably well and even then it tends to be nothing but an educated guess. Even then, I always inflate my estimates by a lot. Best you can do is estimate the things you know and then try to identify the unknowns and add arbitrary times for those, then double everything. It's the Montgomery Scott school of thought: if your estimates are high and you beat 'em then you're a miracle worker. As you gain experience though, your estimates tend to just naturally get better, but they're never going to be perfect.

You estimate how long a FTE (full time employee) could do the task as a singleton.

That way the task will take say 2 days for an FTE, but that FTE may have 3 other tasks at hand, You need to weigh all the tasks that person will be working with over a sprint to determine when these tasks will be delivered.

If a critical issue is brought into play, you add that to the current sprint and the FTE assigned fills in the timeframe when it's dealt with.

You don't report on a single item, but over all.

I'd recommend only giving estimate on stuff that you know how long it's gonna take. And the "this came up", "I don't know how this works", "code review + infrastructure" parts, just say you don't how how long is that going to take. I mean it is true right? Then how could you possibly make an estimate? Usually people tend to insist on getting some shitty number out of you and that's where you have to stay your ground and tell them nothing. Tell them your estimate is good as theirs so they can make it instead. And you wont have to feel bad for making extensions.

Depends on how deep you know the code, if it’s new I’ll give more safe space, otherwise it depends on your behaviour. Also if the client behaviour is an ass, I add in a lot of extra safe space

Depends on a lot of things.

First and probably the most important is there a technical analysis.

If there is it's usually doable to make an estimate. If there isn't you probably can't make an accurate estimate (even when falling back on past experience).

As for the estimation itself, I usually take my initial estimate x2 if I'm developing it, and x3 if someone else needs to develop it.