At some point, really early in a project, you'll be asked how long it will take you to get it done. This is a critical moment for you. You don't want to put yourself in a bind by committing to an unrealistic amount of time and you don't want to take too long.
Finding the right balance is going to take a little trial and error, but here are a few things that will help.
Take a look at the tasks before you say anything
Until you can get a commitment to the scope of the project and all of the expectations, don't say anything about how long it will take you. You can't know how long it will take unless you know what "it" is. Walk through the project or task list with the client or your manager to make sure you understand exactly what they are looking for.
Once you have your expectations, look over them and ask questions about anything that doesn't make sense to you. This is the best way to get an idea of what kind of code you can expect to write. Take notes and don't hesitate to ask even more questions. Keep asking until you both know that you are clear on the tasks.
Look at the average of your coworkers
If you work with other developers this will give you an idea of the average time people expect. Keep a special eye on the developers that have been around for a while. They know their way around the projects and tasks so they usually give the best time estimates.
Remember to account for your skill level too. A junior developer just isn't going to burn through a task list as fast as someone with more experience. Again, watch the other developers because they can give you insight on issues that haven't even come up in the project yet.
Knowing what your co-workers do and learning more about the real expectations for projects will help you think through what needs to be done and in what order. Plus, if you're trying to get ahead of your co-workers a little you know how much more you have to work.
Consider how much testing you need to do
It's not safe to just consider the time it's going to take you to write the code. Include enough time for you to test it as well. Getting a project "done" a week early doesn't matter if it doesn't work. This is your chance to do some QA before it goes to QA.
Your code speaks for itself and the only thing that clients and managers really care about is if it works. A good chunk of your time should be spent on testing and fixing any bugs you find. Don't ignore a bug because you think no one will find it. They will it and they'll find others.
This is one of the things that can get rushed when it's time to deploy. Testing is the thing that will save you the most time because nobody writes perfect code. There's always something that slips through or confusingly breaks. Think about how much time it takes you to catch bugs and factor that in.
Account for the random stuff that will happen
Your dependencies could get out of whack. Your project could stop working. Everything could work perfectly on your computer and then nothing works on the live site. Random things happen in code and it takes time to figure them out.
Give yourself a little cushion to make sure these things don't make you late. This is where you have to use some discretion. There's a difference between adding time as a cushion and adding time to slack off.
You know the pace that you work the best at so don't slow it down or speed it up too much. Part of accounting for random things is accounting for them consistently. The random errors that happen usually take a similar amount of time to fix regardless of the project. Find that amount of time or just ask one of the other developers how they handle these issues.
Estimating time is tricky and it does take some experience. There are going to be times that you don't allot enough hours and there will be times that you allot too many hours. After you've been on 3+ projects it gets easier to see similarities and know some of the issues you might run into.
I had one project that I underestimated hours on so bad that I had to do the walk of shame to my manager and tell him what happened. Don't worry about it. Most of the time people are understanding and if you really put forth an effort they won't hold it against you. (unless you really screw up)
Part of my goal is to help as many people as I can to learn the little subtleties of being a web developer, not just the stuff in the code. Every now and then I send out tips on how to do stuff like estimate time and find new clients. If that's something you're trying to learn more about, you should sign up for my emails! Here's the link.
Okay, I admit to being a freak even among programmers when it comes to project management issues, e.g., time estimation.
I began my programming career as a mathematician who'd already studied advanced topics in Statistics and Probability (Pure Mathematical Statistics, Bayesian Inference, Linear Regression, Auto-Regressive-Integrated-Moving-Averages) and Operations Research (Queueing Theory, Decision Theory, Chaos Theory, Linear Programming). When I ran into the idea that programmers had trouble understanding how to develop project estimates, it took me slightly aback. I simply hadn't considered the possibility that people doing "Extreme Boolean Algebra" (one of my favorite nicknames for programming) would think of all this estimaty-stuff as anything other than obvious or at worst relatively trivial, extra stuff to be learned...my failure - not theirs - I too was young and inexperience once upon a time.
I'm unfortunately frequently reminded that I let my education prejudice my perceptions of others who work in my field. Milica's story was a much needed slap up-side the head. We ain't all trained the same way, and sharing makes us all stronger.
I really do know the part about sharing...teaching others is one of the best ways to reinforce and extend one's own understanding of a topic. I've taught lots. When you try teaching something you (think you) well understand, and your class all tilt their heads like the RCA dog (looking at their masters' voice), it makes you teach harder, i.e., find different words, new examples, etc.
It's the wee, small hours here in GMT-5. I am almost certain to revisit this topic and offer views to expand my grasp of Milica's views and add my own in wider degree.
Estimation - GOOD ESTIMATION - is a MOST important project skill. New developers need to get it. New developers need to understand that, until they CAN reliably estimate time and explain their estimates, they will usually remain juniors in their shops and correctly so. Being good at estimates is important. Better is being able to detail how you arrived at your estimate, whether it was accurate or not. It correctly) reassures your local gods and godesses (PMs, directors, etc.) to hear your reasoning, if it was good, and to understand how some unusual condition nailed you. It's also good for you to have that understanding.
One of the most frequent misunderstandings of decision-making is the belief that good decisions are directly related to the goodness of the outcome of the decision. The decision is good or bad with respect to :
- how well researched/explored the pre-decision space was
- how were most/all available experts polled
- how well were stakeholders interviewed
- were probabilities correctly associated with outcomes
- were decision optimized for overall utilities
The goodness of a decision is a function of how well pre-decision data and probability estimates were collected and incorporated into the pre-decision model, NOT whether the actual outcome of the decision was desirable.
There's a supremely good article that I have squirrelled away somewhere in the morass of things still in moving storage (I and my sweetie will be moving from now until about July of 2019). I'll try to track down the article and provide an online link.
Oh, and any time some PM type attempts to button-hole you in a narrow hallway, to pin you down ambush-style on the timing of delivery of a feature, learn to recite, until it falls trippingly from the tongue..."let me get back to you on that."
Thanks, Milica - You Rule.
P.S. I wrote a time/project article a while back that relates mainly to the management of clients as project resources. This directly relates to some of Milica's points. User, clients, business stakeholders, Project Manages, no matter what you call these non-IT types, all of these stakeholders are integral parts of your estimation process. If you fail to consider and manage them to a fully proper degree, your estimates are worthless.
I posted a copy of the related story at: