Let's talk about estimation.

A sincere guide to help you finish your tasks on time.

I struggle a lot with estimations in my two years as a developer. And I'm not the only one, most of my coworkers struggle with this too.

But why it is so difficult?

I think it's because nobody teaches you how to estimate when you become a developer. You just learn it along the way, coding more and more until you can give a more accurate estimation of how long it will take you to complete a task.

Take your time.

When you are assigned to a project or task, take your time to know exactly what is required. Maybe it's a long project that can take months, or maybe it's a task that only takes a couple of hours.

Whatever the case, you can have an estimation in minutes or it could take you days. Make all the questions you have about the project, make sure the workflow is completed, if you have a design, ask the product team how this will look like in every possible scenario.

What if the requirements are not fully defined?

These are probably the most difficult projects to estimate. If you receive a text from a client who says he wants an e-commerce app but he's not sure about what payment gateway he needs, or the product team delivers a web design for desktop but not for tablet and mobile (this drives me nuts), you probably feel stuck.

It's important to point out that you can't give a precise estimation because you need more information, and that the time you define can be extended due to lack of information.

Dilbert

Split the process.

When you start working, always keep in mind the scope of the project; with that in your head, try to split the process into little tasks and go forward one by one. This will help you to maintain order and to be aware of what have you done and what is left to do. Many apps like Trello and Jira can help you with that. You can estimate this little task also, and that will help.

It's easy to get distracted.

The longer the project takes, the more difficult it is. I remember that I started coding a new feature, and I go back to an older component I made and thought Uhm, I think this needs a refactor. I spent 3 hours on that component, the refactor was done but I loose 3 important hours in something that was out of scope.

Don't get me wrong, there are moments when refactor or tweaking are necessary in order to continue with the task, but for the feature I've been doing it was not. If you want to try a new library or maybe change tons of code, think twice, Is this really necessary?

Alt Text

Communication.

It's key in a team. If you don't understand something, ask, if the product team gives you a design that it's not clever to you, ask the necessary questions.

And most important, when you feel the task or project you are working on is going to take you longer, don't wait until last day to announce this to your manager, yeah I know, we tempted to think that we are going to make it, even when there are two days left until the deadline and there is a lot of things to do, things that normally take you four or five days, we want to finish them in two. That's not possible, or maybe it is, but it will demand a lot of your time, you'll feel stressed, and chances are you won't finished either.

But if I ask for a deadline extension, I could lose my credibility.

There are times when you can't pass a deadline by one or two days and it's not really a big deal, but if a project it's very important, and many areas are going to be affected is this postponed, you need to communicate effectively and detail why this take longer than agreed. This will not take out your credibility, it will reflect your compromise to deliver excellent work.

If you choose to end a project in a hurry, maybe it works or maybe not, maybe it's buggy or you missed something important on the flow. If that is the case you could lose your credibility to deliver a task that didn't complete the requirements.