# How to Estimate Programming Tasks When You Have No Idea

- Link: https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/
- Published: 2026-10-19T09:19:16+03:00
- Author: eJohnny

Someone asks how long a feature will take. You have never built anything like it.
You guess two days. It takes two weeks. Your manager loses trust. You lose sleep.

Estimating programming work is hard because software is invisible. You cannot see
the hidden dependencies, the unclear requirements, or the third-party API that does
not have documentation. But you still need to give an answer.

Here is a practical approach for when you truly have no idea.

![Desk with laptop, sticky notes, and sunlight](https://images.unsplash.com/photo-
1766555766657-ea8f81a67934?fm=jpg&q=60&w=1200&auto=format&fit=crop)

Desk with laptop, sticky notes, and sunlight. Photo by Richard Stachmann on Unsplash.

## 1. Break it down until it is boring

A task like “build the dashboard” cannot be estimated. Break it into pieces that
sound almost silly:

 * Create the database table
 * Write the API endpoint
 * Build the HTML table
 * Add the login check
 * Style the buttons

Small tasks are easier to estimate because there is less room for surprise.

## 2. Use the worst-case-plus-buffer method

For each small task, ask: “If everything goes wrong, how long would this take?” 
Then add 30–50 percent for the things you did not think of.

If you think a task takes two hours in the best case, plan for four. If you think
it takes two days, plan for three. The buffer absorbs interruptions, unclear requirements,
and dependencies on other people.

## 3. Track what you actually did

Keep a simple log of your estimates versus the real time. After a month, you will
see patterns. You might discover that you always underestimate frontend styling,
or that API integration consistently takes twice as long as you think.

Use that data to adjust future estimates, not to feel guilty about past ones.

## 4. Give ranges, not exact numbers

Never say “three days.” Say “two to four days.” A range communicates uncertainty
honestly. If the business needs a single date for planning, take the upper end of
the range and explain why.

## 5. Re-estimate as you learn

An estimate is a snapshot of what you know right now. Once you start working, you
learn more. Update the estimate as soon as you discover something new, and tell 
the person waiting for it immediately.

## The mindset

You are not being paid to be right about the future. You are being paid to communicate
uncertainty clearly so the team can plan around it.

A bad estimate communicated early is better than a missed deadline with no warning.

### Share this:

 * [  X ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=twitter)
 * [  Facebook ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=facebook)
 * [More](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/#)

 * [  LinkedIn ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=linkedin)
 * [  Reddit ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=reddit)
 * [  Tumblr ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=tumblr)
 * [  Pinterest ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=pinterest)
 * [  Telegram ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=telegram)
 * [  WhatsApp ](https://dev.ejohnny.ro/estimate-programming-tasks-no-idea/?share=jetpack-whatsapp)