I think one of the things that is crucial for software developer is that they should have the ability to estimate the time requirement for a task/project. How do I develop this particular skill? Any tips would be help me a lot. Thanks.
Adding on to @ndaidong's answer:
It's incredibly difficult and most often inaccurate to estimate using time. There are so many variables that might be unforeseen/unknown (System downtime, another necessary person may be unavailable, conditions of satisfaction that aren't declared and are unmet) that I've found time estimates to be a very poor measure of estimating. There isn't a developer I know that doesn't, AT LEAST, double the estimate they give (others will even triple or quadruple theirs).
The method I advocate is the Agile method of using difficulty points. This allows you to focus less on how much time you have left and GSD.
Assigning difficulty points to a task will allow you to, over time, show an average estimated time of completion for a task of a given difficulty. For example, you might spend an average of four (4) hours on an 8-point task. This allows those viewing your tasks to see that if you give 8-points to another task, it should take around 4-hours, without committing to it. The business gets what they want (measurable results) and you get to avoid (inevitably) disappointing them with a low estimate or irritating them by always estimating far and above the actual time to completion.
Let the points speak on your behalf.
Don't try! Estimates are dangerous and should be avoided. When someone needs a number from you tell them they can make up their own. It doesn't matter. Better show that you can continuously deliver something of value, say each day. Let the middle managers or team figure out what that means for the bigger picture. I can recommend these presentations:
https://www.youtube.com/watch?v=QVBlnCTu9Ms https://www.youtube.com/watch?v=bicBUVbeR58
This is hard to answer, and depends on several factors, but the main thing is that depends mostly on your own experience. With the time you will develop your own recipe for estimations.
For instance I have a list of items that I check to estimate a task, i.e:
Regards
Mario
Jordan Finnigan
Full Stack Developer
Dong Nguyen
Web Developer
I like the method people do in agile model. That is the most accurate way to estimate I ever known.