The Professional Programmer

Estimation and Time Management

A PM once asked me how long a feature would take. I said "a week." It took three. I wasn't lying—I genuinely thought a week was realistic. I'd estimated the coding time. I'd forgotten about the unclear requirements, the API that didn't exist yet, the meetings, the code review cycle, and the bug I'd spend two days chasing.

Estimates are hard because we're bad at them. The good news: we can get better.

Why Estimates Are Hard

We Estimate Best Case

When you imagine building a feature, you imagine the happy path. You write the code. It works. You're done.

You don't imagine:

The requirement that changes mid-sprint
The dependency that's undocumented
The meeting that eats your morning
The "quick question" that turns into an hour
The bug that only appears in production-like data
The code review that finds a fundamental design flaw

We're optimistic by default. We've done similar things before. We forget how much of that "similar" work was actually different.

The Planning Fallacy

Psychologists call it the planning fallacy: we systematically underestimate how long things will take. It's not a character flaw—it's how human brains work. We anchor on the ideal scenario and underweight the things that could go wrong.

Studies of software projects consistently show that initial estimates are off by a factor of 2–3x. Not sometimes. Consistently.

What We Forget to Include

A realistic estimate includes:

Clarification time — Understanding the requirement, asking questions, waiting for answers
Design time — Thinking through the approach before coding
Implementation time — The actual coding (what we usually estimate)
Testing time — Writing tests, manual testing, fixing what breaks
Review time — Code review cycles, addressing feedback
Integration time — Merging, resolving conflicts, fixing integration issues
Buffer — For the unknown unknowns

Most developers estimate implementation time only. That's roughly 40–60% of the real work.

PERT and Three-Point Estimation

Single-point estimates are wrong. They're always wrong. The question is: wrong in which direction?

Three-point estimation acknowledges uncertainty. For each task, you give three numbers:

Best case (O) — Everything goes right. No surprises. No interruptions.
Most likely (M) — Realistic. Some hiccups. Normal pace.
Worst case (P) — Things go wrong. Requirements change. You hit a nasty bug.

The PERT Formula

PERT (Program Evaluation and Review Technique) combines these into a weighted average:

Text

Estimate = (O + 4M + P) / 6

The formula weights the "most likely" scenario heavily. It's not a guarantee—it's a better guess than any single number.

Example: Building a new API endpoint

Best case: 2 days (requirements clear, no surprises)
Most likely: 4 days (some back-and-forth, normal debugging)
Worst case: 8 days (API design changes, integration issues)

PERT estimate: (2 + 16 + 8) / 6 = 4.3 days

When to Use It

Use three-point estimation for:

Work you've never done before
Work with external dependencies
Work that's critical to a deadline

For routine, well-understood tasks, a single estimate might be fine. The more uncertainty, the more three-point helps.

Breaking Down Tasks for Better Estimates

Big tasks are impossible to estimate. "Build the checkout flow" could be 2 weeks or 2 months depending on what's included.

The Rule: No Task Over Two Days

If you can't break a task into pieces that are each under two days, you don't understand it well enough to estimate it.

Breaking down forces you to think through the work. You discover hidden complexity. You find the parts you're unsure about.

Bad: "Implement user authentication" — 2 weeks

Better:

Set up auth library and config — 0.5 days
Login form and validation — 1 day
Session management — 1 day
Password reset flow — 1 day
OAuth integration (if needed) — 2–3 days
Tests — 1 day

Now you can estimate each piece. The OAuth part might be the risky one—flag it. The rest is straightforward.

Identify the Unknowns

When breaking down, note what you're uncertain about:

"Depends on whether the third-party API supports batch operations"
"Never used this library before—might take longer"
"Requires design input—blocked until we have mockups"

Uncertainty isn't a failure. Hiding it is.

Communicating Uncertainty

Stakeholders want a number. You have a range. The tension is real.

Give Ranges, Not False Precision

Bad: "It'll take 5.3 days."

Better: "Best case 4 days, likely 6, worst case 10. I'd plan for 6 and have buffer for 10."

False precision implies certainty you don't have. Ranges are honest.

Use Confidence Levels

"I'm 80% confident we can hit the 6-day estimate. The 20% risk is the payment gateway integration—their docs are unclear and we might need to contact their support."

This tells them: most likely 6 days, but there's a real chance of slippage, and here's why.

Update as You Learn

Estimates should improve as work progresses. After you've built the first two pieces, you know more. Revise. Communicate the update.

"I've completed the auth setup and login form. The session management is taking longer than expected—their token refresh is more complex than the docs suggested. I'm revising the total estimate from 6 to 8 days."

Early updates build trust. Surprises at the deadline destroy it.

Time Management for Developers

Estimates assume you have time to work. Most developers don't. Their calendars are full of meetings. Their Slack is full of interruptions. "Focus time" is a myth.

The Cost of Context Switching

Every interruption has a cost. It's not just the 5 minutes of the interruption—it's the 15–20 minutes to get back into flow. Three interruptions an hour means you've lost half your productive time.

Deep work—the kind that produces real progress—requires uninterrupted blocks. You can't design a system or debug a tricky bug in 15-minute fragments.

Block Focus Time

Schedule it. Literally. Put "Focus: [task]" on your calendar. Treat it like a meeting you can't skip.

Two hours of focus time is worth more than eight hours of fragmented time. Protect it.

Batch Interruptions

Check Slack at fixed times (e.g., 10am, 2pm, 4pm), not constantly
Batch email the same way
Use "Do Not Disturb" during focus blocks
Set expectations: "I'm in focus mode until 2pm—I'll respond after that"

Say No to Unnecessary Meetings

Not every meeting needs you. Not every meeting needs to exist.

Before accepting: Do I need to be there? Can this be async (Slack, doc, Loom)? Can we shorten it?

The default should be "no" or "maybe async." "Yes" should be the exception.

The Maker's Schedule

Paul Graham wrote about the maker's schedule vs. the manager's schedule. Managers work in hour-long blocks. Makers need half-days.

A meeting at 2pm doesn't just cost an hour—it fragments your day. You have a short morning block and a short afternoon block. Neither is long enough for real work.

When possible, cluster meetings. Give yourself at least one 4-hour block of meeting-free time per day.

Estimation Anti-Patterns

Padding to Cover Your Ass

Some developers double every estimate "to be safe." That has its own cost: work expands to fill the time, and you've trained stakeholders to not trust your numbers. Better to estimate honestly and communicate when you're wrong.

The Reverse Auction

"We need it in two weeks." "Okay, two weeks." That's not estimation—that's negotiation where you lost.

If two weeks isn't realistic, say so. Offer what is realistic. Let them decide whether to change the scope or the date.

Estimating Others' Work

You might be asked to estimate work someone else will do. Be careful. You don't know their context, their skills, their interruptions. Give a range and note the uncertainty: "I'd estimate 3–5 days for someone familiar with this codebase. For someone new, add 2–3 days for ramp-up."

Key insight: Estimates are hard because we're optimistic and we forget hidden work. Use three-point estimation (best, likely, worst) for uncertain tasks. Break work into pieces under two days—if you can't, you don't understand it well enough. Communicate ranges and confidence levels, not false precision. Protect your focus time: block it, batch interruptions, decline unnecessary meetings. Your estimates can't be accurate if you never have time to do the work.