There is no science about time management, everything is clear: you look at your tasks in the issue tracker, you say how long they would take and sum up the numbers. That seems correct, right? Right?

No. Very often this approach let me down.

If you misjudge the time, then the customer starts to get nervous, the project costs begin to increase and the profit decreases accordingly.

If between you and the customer there is a team lead and/or a project manager, then the relationship with these two would cease to be trusting and positive if you time estimation has happened to be far off. As a result the next amazing project they will give to another developer who can correctly predict time required for the project.

You need to predict time better.

Here are some lessons that no one explained to me, I learnt everything the hard way.

Lesson 1

When you are certain about your time estimation don't give in.

Don't be afraid to look like a lazy developer who can't do a simple thing in a reasonable time. If you need a month, then you say so:

I will do this task in a month.

Project manager and director will try to figure out if you really are a lazy developer, and demand to do the impossible - work a way faster (you say month, they say - in a week).

Do not give in under any circumstances!

This leads to another lesson that startups should definitely keep in mind.

Lesson 2

In programming, you can't put more effort and get job done faster.

Software development can be compared to driving in traffic jam. Sometimes the flow starts to move faster, slower, then stops. But you promised to be at the party at 16:00, and already 10 min to 4, but the rest of the route will take 40 min, according to the navigator.

So let's exert, as programmers always do, and get to the party in 10 minutes!

How often did it work for you?

In my projects this is usually a highway, where there are no junctions, no detours, or shortcuts through gas stations.

Let's sum up

When you're evaluating a task, you cannot agree to an unrealistic estimation desired by a project manager.

Entrepreneur: making an overly optimistic time estimation in hope of a magical boost in productivity is a direct road to overtime work and burn-out.

So how to estimate time precisely?

The sense of time comes only with experience. You stop programming and this feeling disappears. You change the development stack, you need to adjust this feeling accordingly.

I felt this when I returned to my old friend C++ after Python/JavaScript, I estimated new project twice smaller than it took in reality.

That's it for today. Thank you for reading.

And, there is a part 2