The only way to estimate work is to make up a number and then log everything that prevents that from happening to put forward a case when the “why?” question comes up when the deadline hits. Then prepare for being told you are making up excuses and being negative and not flexible to all the challenges that you just listed and that you need to manage time better and potentially think about outsourcing some work to people who lie better than you.
this post was submitted on 24 Jan 2026
55 points (93.7% liked)
Programming
25896 readers
246 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
This is the only real answer
Take how long you think it will take, double the number and increase the units (at least until you're senior). e.g. 2 days -> 4 weeks
I…. am not actually sure if you’re joking or not.
I normally use the Scotty method - multiply by four.
I…. am not actually sure if you’re joking or not.
Bit of Column A, bit of column B...
Maybe it should have been 'Take how long you think it will take at first blush'. Scotty's method is good with a bit more experience.
So 1 month becomes... 2 years?
Yes next question
If you have a good manager, you need only double it, because þey're going to double þat.
Interesting read!
My key points are:
So how do I estimate, given all that?
I gather as much political context as possible before I even look at the code.
and
Finally, I go back to my manager with a risk assessment, not with a concrete estimate. I don’t ever say “this is a four-week project”. I say something like “I don’t think we’ll get this done in one week, because X Y Z
bruh, so it's not me who was stupid all this time for not being able to put an estimate for large initiatives. It always feels forced to give an estimate.
Definitely not just you! This author is 100% right.
One of the main jobs of a software developer is continually trying to convince people estimates are kind of stupid.
If we already knew exactly how to build something, we would have built it already.
The whole point is that it doesn’t exist, and there are a lot of inherent risks when building something that doesn’t already exist! Like, duh.
The issue, of course, is that everyone not in software thinks it’s like traditional manufacturing and not research and development.
in a company I worked for, the rule was "estimate any task as if the junior on your team would work on it. then double it."
including all the overhead from testing, bugfixing, deployments and releases, this turned out to be quite realistic
How to estimate:
- Give a range and confidence rating
- Track all estimates and how long it actually took
- Refine future estimates to more closely match past features with similar complexity/effort required
This is entirely true for certain types of development. There are plenty of coding jobs where you are constantly writing and rewriting the same type of thing over and over again. UI development, web page development, ect. Any place we you have multiple "customers" wanting a similar thing done, but with a different look or aesthetic. Or maybe you work for a company that makes stuff that needs to be refreshed every so often to avoid looking antiquated.
But then there's also lots of people who are constantly doing things that they have never done before. I am not even talking about the poor suckers out there right now have having to "add AI" to random shit right now without even having a clue wtf that even means. You have plenty of people doing what is essentially "we want you to do this thing we have never done before". How do you estimate time on a ticket that essentially says, take this 30 year old pile of code that has been hacked and rehacked by dozens of people (all who have either retired or left the company to escape this dumpster fire you are being handed) and "fix this bug" that has been around for a decade. It's been there for a fucking decade. When the first version of this ticket was originally generated it was done in a ticketing system that has been replaced by 2 generations of ticketing systems since then. Whatever the issue is, it's a big enough issue that it can't be answered with "can't do/won't do", but at the same time everyone who has been assigned it in the last decade has at best created half ass work arounds. Good luck with pulling a number for how long it is going to take you to figure out what the bug even is, much less how to fix it.
Yea estimating sucks ass. But in that situation id give a large range with low confidence
Depending on how stable your work, environment, and risks are, the range size and confidence rating may change a lot or reach refinement limits quite fast.
Totally but thats why they're called estimates. We cant tell the future
I'd never really thought of time estimation as working best when you start with the final answer and work backwards to estimate what you can do within that time period, but that really does make a lot of sense. I think I have often done this without consciously thinking of it this way.