Let's take a step back to the real question: is the developer upset because 1. they don't know how to estimate, 2. because their estimate is always wrong, 3.

Let's take a step back to the real question: is the developer upset because 1. they don't know how to estimate, 2. because their estimate is always wrong, 3. they are being held accountable for an estimate that was incorrect, or 4. they feel that it's not their job to estimate the duration of their work? Most people here assume that the issue is #4. However, it's not like they teach estimating skills in school. And the abilities of people vary so much that you'd think estimating would be impossible. But let's go back to the old apprentice/master model for a minute. How much time would it take a master builder to build, say, a classic roll-top desk with a bunch of little drawers out of oak? I think if you surveyed 10 furniture makers their estimates would be within a few days of each other. Then you'd ask them how long would it take for an apprentice to do the same? And I'm sure their answer would balloon tremendously. What's the point of that exercise? Experience matters. When you've done lots of things, and you've paid attention, it's easier to estimate how long it takes to complete things - even if you've never done those things in your life. How long does it take to build an OS? With the right team, it should take about 4 years to build version .9. How long does it take to build a telemetry back-end that scales to a few million clients? Maybe 3 weeks to a month. For someone new who's never touched any of the technologies before? Maybe 4-6 months at a minimum, and that's assuming they're good at integrating things together. So let's get to #1. If you don't know how to estimate, well, you estimate by first trying to figure out the amount of work it takes, then looking at how long it took you to do something of the same complexity/work, then adding some extra time because it's new. You can use your bug tracking system to figure out how long it takes you to fix a bug. What about #2? Well, if your estimate is always wrong you need to find that delta and exploit it. If it took 2 weeks and you said it would take a week, well, try and figure out why. Were you waiting on other teams? Ran into some problem? Couldn't get resources? Or it was harder than you thought? You ran into some unexpected weirdness? Next time, double your estimate. There's a PM rule of thumb that says take your developer estimate, double it, then move it to the next time unit. It actually sort of works when you move it up to the next level ie: include testing/QA, documentation, training, deployment. #3. Are you really going to get fired because you gave a bad time estimate? Then you either need to get better at it or leave. The fact is, anything of any complexity is going to require more people to do, and more people = more time = worse estimates. But it's really up to you to keep people up to date. If you estimate 3 months and you're not even close after a month, well, maybe it's time to tell people and reset expectations. But what the heck are you doing that requires 3 months of work?