Why do meetings ruin a developer's day, and why are estimates always wrong?

Why do meetings ruin a developer's day, and why are estimates always wrong?

A meeting ruins a developer's day because building software requires holding a large piece of a system in mind at once, and an interruption throws that mental state away. Estimates are wrong because an estimate is a guess about work whose difficulty only becomes visible while doing it. Both facts sound like complaints. Both are properties of the work itself, and they show up on every team, including the healthy ones.

These two facts explain a lot of surface behavior that reads strangely from the outside. A developer who declines a 2pm call is protecting the afternoon around it. A team that says "two weeks" and delivers in four has usually done nothing wrong. This lesson covers the mechanics behind both, then defines the planning vocabulary that grew up around them: story points, velocity, and async work.

What is flow, and why does it matter here?

Flow is the state of full concentration where a developer holds the relevant part of a codebase in their head and works inside it. Getting there takes time, commonly fifteen to thirty minutes of reading and re-loading context. Once there, a developer can trace how a change in one file ripples through five others, because all five are in mind at once.

The mental model is the fragile part. It lives in working memory, and working memory does not survive a context switch. A Slack ping, a tap on the shoulder, or a calendar reminder empties it, and the fifteen to thirty minutes of loading starts over. This is why the cost of an interruption has almost nothing to do with the length of the interruption. A two-minute question can cost half an hour, because the two minutes are the question and the half hour is the rebuild.

Flow is why "focus time" appears as a named block on engineering calendars and why many teams hold meeting-free days. It is also part of the picture of what developers care about when they weigh one employer against another. A team that protects focus is offering something concrete, in the same way a sales org that protects selling hours is.

Why does one meeting cost a whole afternoon?

A 2pm meeting splits the afternoon into two fragments, and each fragment can be too short for deep work on its own. If lunch ends at 1pm and the meeting runs 2pm to 2:30, the developer has one hour before it and the rest of the day after it. The hour before is hard to use, because starting a hard problem means paying the load-in cost for a session the calendar will cut off. So the hour goes to email, small tickets, and waiting. The meeting itself takes thirty minutes. Then comes the rebuild after it. A thirty-minute meeting placed mid-block can consume two hours of real output, and a second scattered meeting can take the rest.

The placement matters more than the count. Three meetings stacked back-to-back in the morning leave a whole unbroken afternoon. The same three meetings spread across the day at 10, 1, and 3 leave no block long enough for flow at all. Developers who negotiate hard over scheduling are negotiating over placement, and teams that understand this cluster their meetings and leave the rest of the day whole.

Why are estimates always wrong?

Estimates slip because the difficulty of a software task is discovered during the task. Most of the hours in a piece of work go to the parts nobody could see from the outside: a library that behaves differently than its documentation says, an old decision in the codebase that the new feature collides with, a bug that only appears in production data. The visible part of the task is the part that was easy to estimate, and it is rarely where the time goes.

Construction offers a close analogy. A contractor can estimate a kitchen accurately because they have built a hundred kitchens and the hundred-and-first is mostly the same. Software resists this, because a team rarely builds the same thing twice. If the thing already existed, the team would reuse it instead of rebuilding it, a habit covered in why nobody writes it all. So every estimate is a guess about partially new ground, made before anyone has walked it.

Strong teams respond by estimating in ranges, breaking work into small pieces that fail fast, and re-planning every sprint as facts come in. That cadence is the machinery from how the team moves, and slippage inside it is normal operation. An engineering leader who says "estimates are guesses" in an intake conversation is describing the field accurately.

What are story points and velocity?

Story points are a relative measure of how big a piece of work is, used in place of hours. A team labels a small, well-understood ticket as one point, then sizes everything else against it: about twice that work is two points, a big uncertain piece is eight. The scale deliberately avoids time units. Since real durations are unknowable in advance, the team measures the one thing it can compare honestly, which is size relative to work it has done before.

Velocity is how many story points a team finishes per sprint, averaged over recent sprints. If a team averages thirty points, it plans the next sprint at around thirty, and it can project a forty-five point feature at about a sprint and a half. Velocity turns relative sizes back into calendar forecasts without anyone pretending to know hours.

One property of both numbers matters for anyone reading team metrics: they are local to a single team. One team's three points and another team's three points describe different amounts of work, because each team calibrated against its own history. Velocity forecasts one team's future from that team's past, and that is the whole job. When a candidate mentions points and velocity fluently, it signals time inside agile planning rhythms on a real product team.

What does async mean?

Async, short for asynchronous, means moving work forward through written updates instead of live conversation. In an async workflow, a developer posts progress in a ticket comment, raises a design question in a shared document, and reviews a colleague's work through written code review, each on their own schedule. The sender writes when they finish a thought. The reader responds when they reach a stopping point. Nobody's flow gets broken by the exchange.

Async practice replaces some meetings entirely. Many teams run their standup as a written thread instead of a call, and settle design decisions in documents where the reasoning stays searchable afterward. The written trail is a real byproduct: an async team accumulates records of every decision, which is part of why the habit persists even on teams that sit in one office. "Async-first" in a company description means the team treats writing as the default and reserves live meetings for what genuinely needs them.

Why is remote work so common in engineering?

Remote work spread through engineering earlier and deeper than most fields because the work was already remote-shaped. Code lives in shared online systems, progress is visible in the backlog and the ticket history, and async habits mean collaboration never depended on shared air. A developer's output is inspectable from anywhere, which makes the case for presence weaker than in work that happens in rooms.

Distance can even help. A home office has fewer shoulder-taps than an open floor plan, so the flow blocks this lesson opened with are often easier to find there. That link between remote arrangements and protected focus is why remote and hybrid flexibility carries so much weight in engineering offers, and why it recurs in why developers leave. A req with genuine flexibility competes in a wider pool, and a developer weighing offers is often weighing exactly this.