And yeah, as you may have guessed it: I recently made a mistake with my estimates. I was off by 4x the original one.
Now you can imagine what was the reaction from my managers...
Can't really go into much detail, but at least I would like to share with you all what I learned from this experience:
Dip your toes before you jump in
Make sure you clear any doubts, identify possible issues and try to find any dependencies you might have from other team members. This may require you to ask for more time to plan and come up with a better estimate.
Don't copy other's estimates
It's tempting to use other's estimates as a reference, specially when you are really new to a project, but try not to take them as is. Add some extra time for possible mistakes, take into account how unfamiliar you are with the codebase in comparison with him/her, extra learning time and assistance you might need.
Split big tasks
This is quite a common technique to deal with large tasks and it's totally viable, but remember to consider how the smaller parts will come together and if there might be any possible issue, specially when these smaller tasks can be done in parallel with others. Even "simple" things like merge conflicts can make your life a nightmare.
Never trust yourself
We don't always have a perfect day. Maybe you forgot something at home, had a fight with your family/friend/significant other. Heck, even messing up your coffee can turn you down, all these small things can build up and affect your timing.
Reveal yourself
It's better to say "I don't know anything about X and Y", because this will allow your manager to not only be aware of the consequences of assigning that task to you, but also try to help you overcome them. They might assign it to you and another developer to do pair programming along the way or let him/her know that you might need help and welcome any questions you might have in the future.
Being wrong with your estimates by a considerable time will directly affect the way your coworkers treat you, it's a matter of trust. Try to aim for quality over quantity.
If your estimates are off too often, your coworkers might even ignore your estimates because they no longer trust your ability to do so. Or even worse: set a hard date for you to deliver it, no matter what.
The example I thought of was a case where the work was split too much -- without accurate noting of dependencies within the small bits. It ended up taking 4 weeks to complete 1 user story since it actually had to do about 6 "little" features just to make it actually work and be testable at all.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
And yeah, as you may have guessed it: I recently made a mistake with my estimates. I was off by 4x the original one.
Now you can imagine what was the reaction from my managers...
Can't really go into much detail, but at least I would like to share with you all what I learned from this experience:
Dip your toes before you jump in
Make sure you clear any doubts, identify possible issues and try to find any dependencies you might have from other team members. This may require you to ask for more time to plan and come up with a better estimate.
Don't copy other's estimates
It's tempting to use other's estimates as a reference, specially when you are really new to a project, but try not to take them as is. Add some extra time for possible mistakes, take into account how unfamiliar you are with the codebase in comparison with him/her, extra learning time and assistance you might need.
Split big tasks
This is quite a common technique to deal with large tasks and it's totally viable, but remember to consider how the smaller parts will come together and if there might be any possible issue, specially when these smaller tasks can be done in parallel with others. Even "simple" things like merge conflicts can make your life a nightmare.
Never trust yourself
We don't always have a perfect day. Maybe you forgot something at home, had a fight with your family/friend/significant other. Heck, even messing up your coffee can turn you down, all these small things can build up and affect your timing.
Reveal yourself
It's better to say "I don't know anything about X and Y", because this will allow your manager to not only be aware of the consequences of assigning that task to you, but also try to help you overcome them. They might assign it to you and another developer to do pair programming along the way or let him/her know that you might need help and welcome any questions you might have in the future.
Being wrong with your estimates by a considerable time will directly affect the way your coworkers treat you, it's a matter of trust. Try to aim for quality over quantity.
If your estimates are off too often, your coworkers might even ignore your estimates because they no longer trust your ability to do so. Or even worse: set a hard date for you to deliver it, no matter what.
The example I thought of was a case where the work was split too much -- without accurate noting of dependencies within the small bits. It ended up taking 4 weeks to complete 1 user story since it actually had to do about 6 "little" features just to make it actually work and be testable at all.