Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 5: Estimation Done Honestly #

I want to predict your personal estimation multiplier before you measure it, so that when the measurement comes back you have a calibration target to compare against. If you are an experienced engineer doing solo work, my estimate is that your true multiplier is somewhere between 1.5 and 2.5x — actuals over estimates. You will want to argue with the upper end of that range, because years of professional work have produced a confidence about estimation that feels earned, and the gap between the confidence and the data is the thing most engineers cannot tolerate looking at directly. I am asking you to look at it. Flyvbjerg's database covers sixteen thousand projects across construction, software, infrastructure, and product launches, and the finding is that 0.5% finished on-budget, on-time, with the promised benefits. You are not exempt from this distribution. Your own release history, your past projects, your closed tickets form a personal corpus that, if you collected it honestly, would tell you exactly what your multiplier is. You have not collected it because the act of collection forces a confrontation with the gap. The collection is the deliverable.

The mechanism underneath this module is Kahneman's inside view versus outside view, and the selective read I am asking for is unusual: skip the famous System 1 / System 2 chapters of Thinking, Fast and Slow and read Chapter 23 carefully. Kahneman's own example — his textbook project, where the inside view said two years, the reference class said seven, and reality came in around eight — is the reference example for everything this module teaches. The inside view builds the estimate from the imagined task; the outside view asks what happened the last ten times anything in this class was attempted, by you or anyone. The inside view loses, essentially always, and the chronic under-estimator — the engineer who has said "two more days" on the same task three Fridays running — is not lying. They are answering the inside-view question honestly. It is just the wrong question. McConnell's cone of uncertainty earns its place for one professional sentence it legitimizes: we can give you a 2x range now and a 1.3x range in two weeks, after the design work. Without the cone that sentence sounds like incompetence; with it, it is honesty.

The hardest and most valuable part of the practice is the category-by-category coefficient. The temptation is to compute one global number ("I underestimate by 1.6x") and apply it everywhere; the data is unanimous that this is wrong. Most engineers are not uniformly miscalibrated — they have a pattern: code review 1.1x, refactoring 2.5x, writing 2.5–4x. The pattern is what is actionable, because the reason behind each category's coefficient almost always reveals something about your relationship with that class of work, usually some form of avoidance disguised as efficiency. I will flag the writing coefficient in advance because it shocks nearly everyone: if you have a drafts folder full of stale half-written posts, that folder is partially the artifact of an uncalibrated writing estimate compounding for years — committing a 2-hour slot to what is actually a 6-hour piece, repeatedly, until the draft dies. The corrective is not "write less"; it is assigning writing the time it actually takes when you commit to it. Run the log for three full weeks; with fewer than 20–30 data points per category the noise overwhelms the signal, and a clean small dataset beats a poisoned large one — never estimate post-facto for a task you forgot to log.

One AI-era note, developed fully in M9 but needed here for calibration: the METR 2025 study put sixteen experienced open-source developers on two hundred forty-six real tasks in mature codebases and found AI assistance made them 19% slower — while they predicted 24% faster going in and estimated 20% faster afterward. The size of that illusion should re-anchor how much you trust your felt sense of AI speedup when estimating. If your estimates now silently assume "the AI will make this fast," your multiplier has a new, unmeasured term in it. Measure it like everything else. The two earlier drafts of this module disagreed about emphasis — one pressed the personal-corpus reconstruction from git history, the other pressed the forward-looking three-week log — and the merged answer is to do both: reconstruct ten past projects from commits and issues for the historical multiplier, and run the forward log for the category coefficients. The history gives you the shock; the log gives you the calibration.

Conclusion #

Stop estimating from your gut and start estimating from your measured past. The corpus is the deliverable; Flyvbjerg's 0.5% is your reference class; Kahneman Ch 23 is the mechanism; the category coefficients are where the diagnostic information lives; the cone of uncertainty is the professional vocabulary for communicating ranges without sounding incompetent. Three weeks installs the practice; the next decade compounds the calibration. This is the module whose value-to-effort ratio is the best in the curriculum — three weeks of discipline, ten seconds a day to maintain, and it cleans the feedback loop every other module depends on.

Predictions #

  • Your writing coefficient will be your highest, probably 2.5–4x, and the number will be uncomfortable. The discomfort is the lesson.
  • Code-review estimates will calibrate fastest because the work is bounded; you will have a usable coefficient for that category within a week.
  • Side-project code will carry the second-highest coefficient, and the data will explain why some full days of project work produced one merged commit: the implicit context costs were never in the estimate.
  • Hubbard's calibration self-test will return 5–7 of 10 answers inside your 90% intervals on the first run. The second run, post-module, will be measurably better, and the improvement transfers.
  • Around week two you will be tempted to log post-facto estimates for tasks you forgot. Resist; the contaminated point tells you nothing.
  • Within a month of finishing, you will catch yourself multiplying a gut estimate by your category coefficient before quoting a date to a client or manager. The first time will feel artificial; by the fourth it will be invisible. That trajectory is the Module 5 ROI.
  • You will resist the corpus reconstruction because it requires digging through git history and old issues. Two days of reconstruction saves two years of bad estimates. Around the fourth entry you will catch yourself nudging the actuals to look better. Catch it; the honest number is the only useful one.