Hardest thing about software development to me is estimation of time needed to complete. There should be an algorithm that knows to estimate better than me, shouldn't it? Like google maps navigation knows precisely in advance when I will arrive somewhere taking a car or a train, perhaps they could do my development estimates for me?

It's something you just get better at with experience and practice. It's why I'm a big fan of storypointing, as everyone has to choose together for all stories, it's all relative, and helps those with less experience see the thought patterns of those who've done it before.

@ostream of course there isn't.
And while it's achievable to estimate story points for a task in a sprint, it all gets harder when complexity rises, like giving a rough estimate for a 2 months web project. May seem easy at first sight, but too many details not to be expected, besides obscure edge cases and legacy browser bugs, tools refusing to install etc.

Technically there are techniques to estimate the time.
You make first rough estimation
Then you make Planning/Analysis/Design stage that comes up with all sort of programming product planing, it grows with details about the detalisation, and BOOM! You have full specification of what you are going to code.

Then you adjust your estimation with more or less precise formulas.

....In theory.... if all the project planning is done right, you can get accurate as within 10% of difference value.

In theory at least.

I reached the stage how to do the planing/analysis/planing right now, but how to do estimation I only roughly remembering from the uni.

I guess that requires another book to read.

No estimation is accurate. But the estimation should be corrected in percentage based on the previous completed steps, that will make it more precise.

Basically the accurate estimation should be updated after every completed task. That will make it really up to date accurate estimation.

Short time story, it requires reading
System Analysis And Design 6th edition by Wiley, Denis, Wixom, Roth as a way to start the learning analytic paths (there are actually like more than 7 types of them). That will help to develop basic planning/analytic/model designing skills

Then reading something more about time estimation, and you will be having the knowledge how to do that, probably.

And probably learning more about agile stuff. They have time estimation there too ;b I plan to read more about it later.

the reason why scrum uses Fibonacci or exponential values to determine complexity is because the bigger the task, the harder it gets to estimate. my suggestion is that you break your task in smaller ones, that way you can estimate it better

IMO story estimations suck up the time of the team for no real value as they are often imprecise, due to the fact that to truly estimate a story you would have to have intimate knowledge of every area of the system you have to change and the solution upfront. Not inaccurate estimates, but imprecise.

So I think it's better to take all that time you would spend on estimates and focus on breaking cards down as small as possible whilst still delivering functional value instead, then just take a rough guess at it of 1/4, 1/2, 1, 2, or more days. It should be accurate but imprecise, but now you have got well constructed stories and all the benefits that brings right from explaining the business cases through to PR size and reviews. You can also still give timelines with roughly the same precision.

base = 5 days # sub for your gut feeling
offset = 4 days # weekend days, good measure

X =(base * π) + offset

Always overestimate initially then "bargain" for less.
Make them think they're getting a good deal.

*Usually removing the offset does the trick.

check this https://noestimates.org/blog/

there is a method to predict delivery without the estimates based on the previous delivered work and number of todo tickets.

Check the youtube videos. Second one is better I think 2004year.