"How long will this take?"
I have answered that question wrong more times than I can count. Confidently wrong. "Two days" that became two weeks. "Quick fix" that ate a month. And for years I assumed it was a personal failing — that better engineers estimated better.
They don't. Estimates are wrong for structural reasons, and understanding those reasons is the only thing that ever helped me. Here's why your estimates are always wrong, and what actually moves the needle.
Your estimates are wrong because software estimation is predicting the duration of work you haven't fully understood yet — and you can't accurately predict what you haven't discovered. Padding doesn't fix it. What helps is estimating ranges instead of points, breaking work down until the unknowns surface, tracking your own historical accuracy, and treating an estimate as a forecast that updates, not a promise carved in stone.
Here's the root of it. When someone asks "how long will this take?", they're really asking you to predict the duration of a journey through territory you haven't mapped yet.
If the work were fully understood — every edge case, every integration, every surprise — it would already be half done. The reason it needs doing is that parts of it are still unknown. And you cannot accurately estimate the unknown. By definition.
So every estimate is really a guess about how many surprises are hiding in the parts you haven't looked at closely. The "two days that became two weeks" wasn't bad math. It was the third-party API that behaved nothing like its docs, the edge case nobody mentioned, the refactor the task secretly required. None of those were visible when I gave the estimate.
An estimate isn't a measurement of the work. It's a guess about how many unknowns are hiding in it.
This reframe matters because it stops you blaming yourself and starts you attacking the real problem: reducing the unknowns before you commit to a number. Learning to talk honestly about uncertainty instead of performing false confidence is one of the quieter parts of the brutal truth about becoming a senior developer.
Even setting aside unknowns, your brain is rigged to underestimate. It's called the planning fallacy, and it's one of the most robust findings in all of behavioral science: people systematically underestimate how long their own tasks take, even when they know they've underestimated before.
Why? Because when you imagine a task, you imagine the happy path. The version where everything goes right. You don't imagine the meeting that derails Tuesday, the dependency that breaks, the "while I'm in here I should also fix…" rabbit hole. The American Psychological Association has documented the planning fallacy for decades — it's a stable cognitive bias, not a personal weakness you can willpower away.
You estimate the best case and then reality serves you the average case, which always includes some friction.
The cruelest part: experience doesn't cure it. Senior engineers underestimate too — they've just learned to multiply their gut number by some painful personal constant. Which is itself a kind of admission that the gut number is structurally too low.
If unknowns are the enemy, the cure is to convert unknowns into knowns before you estimate. And the tool for that is breaking the work down until it stops being scary.
Here's the pattern I trust now. A vague task is a black box full of surprises. Break it into pieces, and three things happen:
A task you can't break down is a task you don't understand well enough to estimate. The inability to decompose is the warning sign — the same signal I leaned on heavily in the engineering habit that doubled my output.
// "build the import feature" -> 3 days?? (a guess about a black box)
// break it down:
// - parse the CSV -> 0.5d (known)
// - validate rows -> 1d (known)
// - map to our schema -> ?? (UNKNOWN - their format is weird)
// - handle partial failures -> ?? (UNKNOWN - what's the UX?)
// - dedupe against existing -> 1d (known)
// the two ?? lines are the whole risk. now we know where to look first.
Suddenly the estimate isn't a single brave guess. It's a sum of small known pieces plus two clearly-flagged unknowns I should go investigate before promising anything.
This one change improved my estimates more than anything else: I stopped giving single numbers.
"Two days" is a lie of false precision. It hides all the uncertainty in a confident-sounding point. The honest answer is almost always a range, and the width of the range communicates the thing that actually matters — how much you don't know.
| What you say | What it really hides |
|---|---|
| "2 days" | All the uncertainty, pretended away |
| "2 to 5 days" | An honest signal of moderate unknowns |
| "2 to 10 days" | A loud signal: go reduce unknowns first |
| "I need a day to scope it" | The healthiest answer to a fuzzy task |
A wide range isn't you being wishy-washy. It's you being honest about risk, which lets the people planning around you make better decisions than a confident wrong number ever could. A two-to-ten-day range is a flag that says "this needs investigation before anyone commits to a date" — and that flag is worth more than a comfortable lie.
The last piece is humbling and effective: measure how wrong you actually are.
Most engineers never compare their estimates to reality. So they never calibrate, and they repeat the same optimism forever. I started keeping a dead-simple log: what I estimated, what it actually took.
The pattern that emerged was brutal and useful. My tasks took, on average, around twice my first instinct — and the more confident I felt, the worse the ratio, because confidence meant I'd skipped the decomposition. Now I have a personal correction factor based on real data, not vibes.
A few practical habits that fall out of this:
Q: My manager wants a single number, not a range. What do I do? Give the range and then offer a single number with the explicit caveat that it's the optimistic end. "If you need one number, call it five days, but it could be eight if the integration is messy." You've answered the question and protected yourself with the truth.
Q: Doesn't padding estimates solve this? Padding is a blunt instrument that hides the reasoning. A padded number you can't explain gets negotiated down by anyone who senses the padding. Decomposition and ranges are honest padding — they show where the risk is, which is far more defensible.
Q: How do I estimate something I've genuinely never done before? Don't, yet. Ask for time to build a small spike or prototype first, then estimate from what you learned. Estimating truly novel work without any investigation is just creative writing. Convert the unknown to a known, then commit.
Q: Why do my estimates get worse for bigger projects? Because unknowns compound — and dependencies between tasks multiply the risk. A ten-task project isn't ten times as uncertain; it can be far more, because tasks block each other in ways you didn't foresee. Break big projects into independently shippable chunks and re-estimate at each one.
Q: Will I ever estimate accurately? Not perfectly — nobody does, and chasing it is a trap. The realistic goal is to be calibrated: to know your own bias, give honest ranges, and update fast. A consistently-wrong-in-a-known-direction estimator is genuinely useful. A confidently-precise one is dangerous.
Your estimates aren't wrong because you're careless or bad at math. They're wrong because you're being asked to predict a journey through unmapped territory, with a brain wired for optimism, under pressure to sound confident.
An estimate is a forecast, not a promise. The honest unit of estimation isn't a number — it's a range whose width tells the truth about what you don't yet know.
The fix isn't to estimate harder. It's to break the work down until the unknowns show themselves, speak in ranges, update as you learn, and track how wrong you've been before. Do that and you won't become a perfect estimator — but you'll become a trustworthy one, which is far more valuable.
If this reframes even one estimate from a brave guess into an honest range, try it on your next "how long?" — and the senior-developer pillar gathers more of these career-shaping shifts.
So next time someone asks "how long will this take?" — what would it look like to answer with an honest range and a plan to shrink it?
Leaving my job wasn't a leap of faith. It was a spreadsheet. Here's the runway math that turned a terrifying gamble into a boring, calculate…
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!