How I went from "probably a week" to "2.75 days"

When I started my career as a developer, I was the bottom of the team. I had one goal: become someone my lead could trust. The condition was simpler than I expected. Whenever a task was assigned — no matter how small — I'd estimate it, write "I think this will take about X," and put a due date on the ticket. Surprisingly, a lot of people struggled with just that part.

Even in the age of AI-boosted productivity, "how long will this feature take?" is still the question. So here's what I've learned from years of actually timing myself.

(The examples are dev-oriented, but estimation isn't really a domain-specific skill.)

Your real focus time is half of what you think

When I first started using Pomodoros, I was sure I'd hit 12 sessions in an 8-hour day. 25 minutes on, 5 minutes off. The math checks out, right?

I averaged 6. Three hours of actual focused work.

If that sounds low, try it for a week. Meetings, Slack, "quick questions," context switching, the 5-minute thing that takes 40 — one clock hour produces maybe one Pomodoro of real output.

6 Pomodoros? A solid day. 8 to 10? Happens two or three times a month. Those are the days you leave the office thinking, "Yeah, I earned it today."

The remaining 5 hours aren't wasted, though. Meetings, small talk with coworkers, grabbing coffee, the work that makes work possible — organizing docs, breaking down tickets, checking blockers. It doesn't feel productive, but without it, nothing actually moves.

So when I estimate, I count 1 day = 6 Pomodoros. If it's an "ASAP, everything's on fire" situation, I stretch to 8 — and that's one day.

Estimation is about sequence, not prediction

A bigger shift than tracking time was learning to break work down in order.

When I estimate something, I list every step from the current state to the goal state. In order. What comes first matters more than how long each step takes.

Think about moving apartments. You send the truck before you have the keys. The furniture's on the sidewalk, the door won't open, and it's raining.

The same thing happens in production. You ship a new UI, but the backend isn't serving that data yet — users see a blank screen. Ten minutes to fix, but in those ten minutes, support tickets roll in.

So when I break work down, the first question isn't "how long?" — it's "what comes first?"

This matters especially when you're making big changes to a live service. You're swapping the wheels on a moving car. Get the order wrong and it's hard to undo. At some point you'll be waiting on another team, and that wait time is part of the estimate too.

I call this process a rough draft — before the actual work, I write out the flow at pseudocode level. Not real code, just "do this here, then that, this part might get stuck." Thirty minutes of that and you can tell whether something is a 3-day job or a 5-day one.

(At one team, this rough draft practically was the work. Their requirements docs were so rigorous that versions went up to v60 — at that point it's basically implementation. Most tickets at that team ended with "~draft document" or "~write spec.")

Even with all that practice, unfamiliar domains and heavy dependencies make even the estimate-of-the-estimate hard. When the CEO or PM asks "how long?", sometimes the honest answer is "figuring that out will take a day."

Scoping is estimation too

The hardest part of estimation — and the one people most often skip — is uncertainty beyond your control. Other people's feedback, delayed decisions, shifting requirements. You can't pad the timeline forever, so you have to draw the line somewhere.

I set a cap on feedback rounds. How many depends on the project, but without a cap, it never ends. Past the limit, remaining items get pushed to the next version — unless it's a bug or a critical pivot.

Estimation isn't just "how long will this take." It's also "this is where we stop." Without that boundary, you're estimating an infinite loop. So I write not-to-dos on every ticket. Writing "we're not doing X this time" upfront gives you ground to stand on when someone inevitably asks "can you also do X?"

As I break tasks into subtasks, uncertain ones pop up in between — unclear importance, unclear feasibility. I mark these as optional and estimate with "try it, skip if blocked." It's the gray zone between not-to-do and must-do. Marking it early means when things slip, you know exactly what to cut first.

These optionals are worth discussing proactively — especially on deadline-driven projects. It's harder in siloed orgs, but it works where communication is relatively open.

And this is where trust gets built. "Optional" doesn't mean "great, I can skip it." It means you check feasibility, and if it's easy to bundle with other work, you throw it in as a bonus. When you do that, the people sending requirements start layering them thoughtfully — required vs. optional. It's a virtuous cycle.

Not that I always estimated well. Unfamiliar territory means uncertainty, and uncertainty means bigger buffers. I happened to build a lot of side projects because I wanted to go solo someday — and that turned into subtask-level experience. (Filing a business registration on my own meant I could estimate the exact same task at work instantly.) More things I've done, more accurate the estimates — even at new companies and new domains.

Then AI broke the unit

These days I barely use Pomodoros. Not because the method stopped working — the sessions got too short. Tasks that used to fill a 25-minute block finish in 7. Some take seconds. Even the longer ones rarely exceed 25 minutes. The unit doesn't fit anymore.

What changed more is the shape of the work itself. I queue up tasks for AI, come back to review, queue again. The parallelism is on AI's side — I still can only look at one thing at a time. Reviewing AI's output becomes its own work, and on dense days, it's physically exhausting. A different kind of fatigue from deep focus.

I spent years measuring my time and learning to estimate honestly — as a full-time developer, on freelance projects, and across side projects. But now the unit itself is shifting, and I'm still looking for something to replace the Pomodoro — not a timer, but a way to gauge a day.

And a more fundamental change — the people and contexts that ask for estimates are shrinking.