Your estimate will be wrong, the question is which day you see it

In a small team the estimate gets given in a conversation. Someone says this will take two weeks, the other person nods, and that is where it ends. Two weeks pass and the work is not finished, the week after that it is not finished either, and in the fourth week somebody turns round and asks what happened. By that point the thing being discussed is who is slow. That job was never going to be done in two weeks and it was clear by the end of the first day, but you spent four weeks finding that out.

If an estimate is wrong it is wrong, the question is when you see it. However senior you are, we are all human, making mistakes is in our nature, and estimates like this are wrong almost every time. Especially if you have not built a similar game in that genre, you cannot even work out where the main effort is going to go. Sometimes a UI problem you never saw coming eats half your time. It is not a question of resources either, because there are problems that need to reach a certain maturity before they are solved, however many people you put on them. If one woman gives birth in nine months, nine women do not give birth in one.

Before you can see that your estimates are wrong you have to go through a Dunning-Kruger first. It is a sense that only experience buys. When your technical capacity is low your confidence in yourself and in your estimates is at its highest, because you do not yet know what you do not know. Then the project puts it in your face that you are not that good a fortune teller. There is something old-school programmers always say, if a job is going to take two weeks write four, because something unexpected always comes up. It is worth not overdoing that offset, though. The longer you give a task the more that task expands to fill the whole time, so the padding you added does not come back to you, it only gets spent.

When you say this will be quick, the pressure of that estimate usually beats you and you end up cutting features, or giving up the polish the thing needed, to make the date. You crunch to get there anyway, and the crunch is usually not enough either, and the quality that comes out at the end is lower than it should have been.

On work you have already done dozens of times, your estimate usually holds. The measure is simple: if you cannot describe a job end to end, step by step, you do not know it as well as you think you do and your estimate will not hold. That inability to describe it hands you exactly what you need. Break the work into as many pieces as you can describe and write each piece its own day. If the first piece is not done at the end of the first day, that job is not finishing in the time you gave it, and you learn it on the first day instead of in the fourth week. If it is work you have never done, break it into hours. Being aware of this is worth more than giving a consistent estimate, because a consistent estimate is only ever built on top of that awareness.

These arbitrary deadlines are especially rough on people working alone, because when you miss the time you gave yourself you either pile on more than you should, telling yourself you were supposed to have finished, and walk into burnout, or you stop caring entirely and stretch the project out forever. Hundreds of games have passed through my hands and I still have not seen the middle ground.

So stop trying to get your estimate right, it is not going to happen. The only question is which day you see that it was wrong.