I am a coder in a startup right now and we handle tasks step by step. I am switching context for codebases and change languages a lot and I like it.

But I guess I have a problem. In a meeting with my manager, she said she couldn't trust me about the deadlines because I never finished in the time I gave. That got my motivation down in the morning of the day.

Another task was given to me while I was coding for a task, and I finished another task too, so the task was a little late and I told them that. As I told them towards the end of the task, they may have misunderstood and she said the misunderstanding is my fault.

I will now multiply the deadlines that come to my mind with 2 after that. I write fast code and try to get things done, even all, but things are not finished. I started to think that I was not suitable for the business life because of that. I started to think that my managers are talking about me behind my back, and this lowers my motivation.

As @LokiRagnarok commented; I would love to get advices on these;

  • get better at estimating deadlines
  • improve communication with my manager
  • emotional response to criticism

Thanks for all responses.

  • 1
    Read Spolski's blog as to how to make estimates and estimate velocities. It's not hard science, but it's not a dark art in industry either. Commented Jun 5, 2020 at 11:59

5 Answers 5


(People are going to answer saying you should be employing methodology x, and your system is flawed because you should be doing y. But I'll try to keep the assumptions down to a minimum).

Fundamentally as you gain experience you will get better at estimating and your manager will become more understanding over time.

In the meantime, you need to be more conservative with your estimates. Assume you will take longer to complete tasks.

Also, if you feel like an estimate may be incorrect, you need to tell them when you realise. People don't like missing deadlines, but they HATE being surprised about missing deadlines.

You should work with a more senior member of possible to double check your estimates, if that is possible.

It's pointless worrying about who is saying what behind your back. The important thing is you keep working the best you can and trust things will improve.

  • Thanks for saying up front that this is NOT a methodology or tools problem. It all comes down to the fact that the OP is just one link in a chain of promises that the organization is making to a customer. When the OP "breaks" that link by not delivering, it puts the whole organization into trouble.
    – teego1967
    Commented Jun 4, 2020 at 12:23

There maybe several issues at work here. Who gave you the additional work while you already worked on the first task? The same manager? If so, then tell them right when they hand you this task that this will delay all other tasks. Now, they can clarify which task is more important.

If it was not your manager, did the other person have the right to give you work? It might be nice to be nice, but your Number 1 should be your manager. So tell this person to run this task by your manager, so that your manager can prioritize.

If everybody can give you work and expects it done as priority 1, that's a recipe for trouble. So you should clarify with your manager how works gets assigned and prioritized.

If you have a regular workload for some set of certain tasks, factor those into your estimates. as you effectively have left less hours for your other tasks.

While at this, instead of blaming others, try to state the facts as neutral as possible. And try to have an attitude of: Ok, there were some miscommunications in the past, how can we improve this?

There is the added issue that estimating is HARD. Super hard. And some people mistreat estimates as gurantuees. If your manager is such a person, pad your estimates. I had managers where I had to do this. I had another manager, he simply had a factor in his had he added to the estimate of every single person. For some persons, he regularly trippeld their estimates before communicating with upper management!


What you and/or your manager are confusing is the difference between a deadline/completion date and duration.

A task that takes one day will usually not be done tomorrow, because you will get interrupted by other work, so even though you spend only 8 hours on it, it could take 2-3 days until it's actually done.

There are several ways to go about it which can also be combined, though all have advantages and disadvantages:

  • Talk to your manager about the distinction and make it clear that your estimates are always durations, not completion dates. That also means that you need to avoid saying "I'll get it done by Friday," but instead "It'll take me two full workdays."

  • Keep track of roughly what percentage of the day you can spend on work for that manager and adjust your estimates. For example, if roughly half of your work is spent doing other stuff, you'll double your estimates.

  • Communicate changes of your completion dates whenever new work comes in. For example, if you are doing tasks for Manager Alice and then Manager Bob comes in and gives you a new task that takes 4 hours, send an E-Mail to either just Manager Alice or both Manager Alice and Manager Bob to inform them that your former task will be delayed for 4 hours, the new completion date is X. Leave it to the Managers to argue over which task has more priority.

  • Keep a strict schedule. For example, you're open to work from Manager Bob in the mornings, but once the clock strikes 12, you only do work for Manager Alice. Calculate each day as 4 hours of productivity and estimate accordingly, e.g. "I'll do the job in 3 afternoons, so it'll be done by Tuesday."

  • Inform the manager every day on how much time you were able to spend on a task compared to how much you planned to spend. For example, every day at 5pm you send a mail "I've spent only 4 hours working on task X, because task Y took 2 hours and task Z took another 2 hours."

Overall, the problem you have is very common and it's primarily an issue that can be solved by communication, though depending on the people involved some of the solutions might work better than others. Many methodologies were developed to deal with exactly that problem, though all of them depend on the managers supporting the process and methodology.

Personally, my choice would be a combination of making sure of the distinction between completion date and duration by always only using durations, as well as communicating any additional, short-term tasks and their estimated duration to the managers upfront.


You really need to be very conservative in your estimates. When I started as a Junior dev, my boss asked me for a feature in a long-running product I had taken over, and I told him that this would maybe take 1-2 months, max. I was very nervous because that seemed outlandish. He even pushed back on that estimate, like "yeah, we have done x, which is almost like this thing y, so that shouldn't take that long, dude".

That is what bosses are like, they want everything to be done the moment they have come up with the idea.

It took three times as long, almost half a year, because the project consisted of a lot of legacy code with very little documentation, and I had to coordinate my workflow with another developer.


Your “manager” doesn’t seem to understand the meaning of the word “deadline”. Having a deadline means you have to deliver at that point, or there will be significant legal or financial consequences for the company. When there is any danger of missing deadlines you hire more people, or you pay overtime, and you certainly don’t add other tasks. What she has may be targets, or estimates. You don’t estimate deadlines.

Since your manager is out of control, your estimates (not deadlines, estimates) should be like “my best estimate is that I’ll need two days of uninterrupted work to finish this”, not “it will be finished in two days”. When she comes back in two days complaining you can then say “I said I’d need two days of uninterrupted work, so far I had less than four hours”.

For your emotional response: She seems to be quite useless as a manager, so take that into account. If she says it’s your fault that means nothing. As a developer I can tell you: Never rush. A job that you rush takes longer. Write your code until it works, then you clean it up, then you test it. All without rushing. You may safe two hours by rushing and in three weeks time you waste a day fixing a bug that you introduced by rushing.

  • 1
    Not my DV, but you seem to rely a lot on the definition of a single word to characterize the manager, while it's obvious the OP is not a native speaker themselves and has not quoted their manager verbatim.
    – nvoigt
    Commented Jun 4, 2020 at 10:56
  • I am really sorry for my lack of English, these were words but I think I must do not think about it and I must seem not affected from anything because of make us earn.
    – user118708
    Commented Jun 4, 2020 at 11:21
  • I find your interpretation of "deadline" to be a little strange, and it doesn't match my usage. When I ask team leaders or developers to commit to a date for a piece of work, I'm looking for a deadline, and I say so. Its part of their job to manage their time, but if they say its going to happen, I will hold them to it, subject to extenuating circumstances, I take these very seriously, since I've been part of a lot of software organizations that cannot deliver on time. Perhaps I've been using the wrong word.
    – Damouse
    Commented Jun 4, 2020 at 15:43
  • @Damouse No. You haven't been using it wrong. Not all deadlines are due to regulatory purposes. Different businesses will have different ways of operating. Deadlines are very important when there are lots of moving pieces and a delay by one person can have consequences, which it sounds to be the case with how you've worked in the past. Commented Jun 5, 2020 at 1:32

You must log in to answer this question.