Estimates are not promises
One of the most annoying misunderstandings I see in tech is treating a software estimate as a hard commitment
We’ve all been there: you get dropped into a legacy codebase that someone else hacked together over six months. At the same time, your calendar is a minefield of recurring meetings, you’re trying to shipping a minor release on another project, and people keep dropping by with "just a quick question." Then someone asks: “When will this feature be ready?” The honest answer is: “I have absolutely no idea.”Especially when you're dealing with third-party APIs, zero documentation, and a system where the entire context lives exclusively in one senior dev's head
But you can’t just say that. So instead of guessing a random date to make management happy, we need to treat estimates for what they actually are: hypotheses, not promises. A realistic answer sounds more like this: "Let’s aim for Friday. That’s assuming the scope stays the same, I actually get the API keys today, and I don’t get pulled into emergency firefighting. If priorities shift, the date shifts."
This isn't pushback or being difficult. It’s just how reality works. Uncertainty is always at its peak on day one, and you can't just "think harder" to make it disappear. As an engineer, you don't owe anyone a perfect psychic prediction. What you do owe the team is making that uncertainty visible
The math here is simple: - More scope = new date. - More meetings = less focus time. - No handover = discovery phase comes first
Estimates don’t exist to guarantee a perfect timeline. They exist so we can manage reality instead of just praying things work out
(picture of a cat for attention 🤓)