The real score or why deadlines come?

As an experienced project manager, I often came across deadlines for programmers, multiplied them by Pi and took the next order. So 1 day turned into 3.14 weeks. I learned in my own skin that programmers are worthless appraisers.

For greater accuracy, I made a table that helps to translate programmer's estimates into reality.

Evaluation	Programmer's reasoning	What the programmer forgot	Valid Rating
30 seconds	There you need to fix quite a bit of code, I know where it is and what to do.	Time to turn on the computer, boot the environment, open the desired project, tests, projects, builds, documentation ...	1 hour
5 minutes	This is a small problem, now I’ll google it and fix it quickly.	It is rarely possible to find what you need the first time, but even if it was found, then it must also be finished with a file, at least. Add builds, tests, projects ... well, as it should be.	2 hours
1 hour	I know how to do it, I just need to sit down and write, it will take a little time.	One hour is not enough to cope with the "suddenly out of the way" emerging problems, and they, unfortunately, always appear	2 hours
4 hours	I need to walk a little, I can imagine what to do, I need to use the Wizzabanga module, or ... I don’t remember exactly ... well, from our framework, I just read the docks.	This is probably one of the most accurate estimates. Most likely the task is small, but for unforeseen difficulties there is still a little time.	4 hours
8 ocloc'k	First, I will need to refactor the Balunga class, then I zayuzayu Wizzabanga and at the end add a couple of fields on the gui.	The system has many dependencies on the Balunga class, refactoring will affect about 40 files. Those fields that appeared on the GUI should be reflected in the database and admin panel. The programmer missed many steps in the evaluation.	12-16 hours
2 days	There will have to work, I will create a tablet in the database, and then add the logic of working with it.	Of course, there are trifles, and not only trivia, which were not taken into account by the programmer. Most likely, large pieces of the functionality necessary for the implementation will emerge, and the programmer did not take into account one hundred percent.	5 days
Week 1	Oh ... it's just a HUGE task! I have never done this before, but I am not saying that I can’t do it. I think the week will be enough, but, unfortunately, I can not give a more accurate assessment.	The task is too big to be fully understood by most programmers. It should be sent back to the architect, so that he broke it into subtasks and gave the correct instructions in implementation. An important fate is entrusted to the architect; he must simplify the task and give the programmers a few small and clear tasks.	2-20 days

')
It is difficult to evaluate.

Each programmer makes the assessment partly correct, but almost always forgets about the overhead (debugging, tests, etc.). Exceeding the deadlines means that the task is too large and it had to be divided into subtasks.

For juniors, the “correct part” of the assessment may simply not exist. They will evaluate almost at random, because so many things, in the light of lack of experience, seem to be non-trivial. Experienced developers should give accurate estimates in the range from 0.5 to 24 hours. What does not fit in 24 hours should be broken apart. This should occur in the head of the developer, and then these parts should be folded.

It is important to understand that programming experience and evaluative experience are two different things. A good programmer who has never evaluated anything once will not give a qualitative assessment the first time. It should also be understood that without comparing the real time spent with the initial estimate, you will not learn anything.

As a result, each programmer must use his experience to give an assessment. To achieve a good level, simply evaluate each, even a small task that you do. After the task is completed, simply compare the lead time with the estimate you made. This should develop two things in you: taking into account and understanding all the details of the task and the accuracy of the assessment.