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)
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding