“What should I learn to make senior?”
I get asked this a lot. The expected answer is a reading list — system design, a second language, design patterns, maybe distributed systems. All worth learning. None of them is the answer I actually give.
Learn to estimate.
It surprises people, because estimation doesn’t feel like a skill. It feels like a chore, a formality, the thing the project manager makes you do. But getting good at it is one of the fastest ways to be seen as senior — for a simple reason. It’s the most direct, most public demonstration of judgment you have.
Output versus foresight
A junior developer is judged on whether the code works. That’s table stakes — necessary, but it’s the floor, not the ceiling.
A senior developer is judged on something harder: whether what they said would happen actually happened. Will this take two weeks or two months? Will this approach scale or fall over at 10x? What breaks the day we ship it? Seniority is, mostly, calibrated foresight — and an estimate is that foresight made legible. It’s the moment you put your judgment in writing, where everyone can check it against reality.
That’s why it moves the needle on how you’re perceived. Good code earns quiet respect from the few people who read it. A good estimate earns trust from everyone — including the people who will never read a line you write.
Why it makes you better at everything
Here’s what makes “learn to estimate” such good advice: you can’t do it well without doing everything else well first.
To produce an estimate you actually believe, you have to break the work into pieces small enough to reason about, find the parts you don’t understand yet, and — the senior move — anticipate the ways it will go sideways. Juniors estimate the happy path, because the happy path is all they’ve seen. Seniors pad for the integration that’s always worse than it looks, the requirement that isn’t really decided, the “quick” migration that quietly owns the next month. That padding isn’t pessimism. It’s memory.
Estimating well forces you to think like an architect, a risk manager, and a translator all at once. Get good at the estimate and you’ve quietly gotten good at the rest.
The good news: it’s trainable
The strongest argument for “learn to estimate” is that estimating is a skill, not a talent — which means you can deliberately get better at it.
That’s the central finding of Philip Tetlock’s work on forecasting. Across the Good Judgment Project — some 25,000 forecasters and roughly a million predictions — the people who forecast well weren’t smarter or better connected. They were better calibrated, and the calibration came from practice with feedback: make a prediction, write it down, then check it against what actually happened. The skill persists year over year. It’s real, and it’s learned. (Tetlock and Paul Schoemaker even made the business case in HBR — Superforecasting: How to Upgrade Your Company’s Judgment.)
The catch is the feedback loop, and it’s the exact loop most developers never close. We estimate, the number goes on a board, the project happens — and almost no one circles back to compare the estimate to the actual. Without that comparison you can estimate for twenty years and never improve. With it, you improve in months.
How to actually practice
If you want to use this to level up, it’s refreshingly concrete:
- Write your estimates down — even private ones, even “this’ll take an hour” — then record what it actually took. That one habit is most of the skill.
- Track your error and your bias. You’re almost certainly optimistic; once you know how optimistic, you can correct for it. Most of us run a personal “multiply by two” we haven’t admitted to yet.
- Estimate in ranges. “Half a day to two days” is honest, and it forces you to name what would push it to the high end.
- Use the outside view. Before estimating from imagination, ask what the last few similar tasks actually took. History predicts better than hope.
Do this for a year and you’ll be the person whose numbers people trust — which, more than any framework, is what “senior” means in the room.
The whole point
Seniority isn’t knowing the most. It’s being the most reliable about what is going to happen — and being honest when you don’t know. Estimation is the most direct way to build that reliability and the most visible way to prove you have it. (It’s also why a bad estimate can sink a good team — but that’s its own story.)
It’s why we run senior-only teams. The estimate is part of the deliverable, and a good one takes someone who has been wrong enough times to be right about it now. Software that’s too important to get wrong needs people who can tell you, before the work starts, what getting it right is actually going to take.
Sources & further reading
- P. Tetlock & D. Gardner, Superforecasting: The Art and Science of Prediction (2015) — the Good Judgment Project
- P. Schoemaker & P. Tetlock, Superforecasting: How to Upgrade Your Company’s Judgment, Harvard Business Review (2016) — hbr.org
- Related: The estimate is the verdict — how a good estimate decides whether a project is called a success
Facing this yourself? See our related service →