I think there are multiple issues needing to be addressed, but the main one I want to resolve is in the question title.

Some background context:

I'm somewhere between a junior and mid level software developer; I have 3 years of industry experience. I work in a relatively small company (< 20 software devs) and am usually put on projects either solo or in a very small team. These are managed by a high-level PM who has almost nothing to do with development and is barely involved in the project beyond the initial and final stages, and there is also a team lead, usually a more senior developer, although their role is more of a scrum-master type since they're typically not actively involved in development.

Because we're such a small company, we have to:

  1. Take whatever work we can get, and
  2. Be as cheap as possible

The way we stay cheap is to basically compress development into as short a timespan as possible. This means we almost never actually have enough time to do the work if we worked normal hours; as such there is an implicit requirement that we'll do overtime. Projects usually have a turnaround of a few months.

I usually come into projects at the point where we've got some basic, vague user requirements and agreed timescales, and am then basically told "go do it."

I then need to do the following:

  • Understand the domain and any existing code and tools, which can be quite complex and require very specific knowledge
  • Understand the user requirements, make any designs
  • Create work items and associated time estimates
  • Develop, test and document the solution

It seems like the only thing that has been factored into the overall project timescales is the development time.

There is typically not much support. Internally, the team lead can sometimes help with general software development issues, but because they're not really involved with the project's development at a low level, any specific blocking issues are up to me to resolve alone. The customers are also largely absent except for sprint reviews and occasionally responding to emails.

The worst cases are usually modifying existing legacy projects which have bloated codebases and are poorly documented, and the original developers are nowhere to be found; these take me so long to understand and work with.

I usually feel like I'm right up against it, and it can be exhausting. Tasks almost always take longer than my initial estimates, which then makes me look bad, like I'm not being productive. I usually end up having to rush things towards the end. I do tell my team leads about this, and they usually say something like "Well, just do as much as you can."

The projects get delivered (usually) on time and on budget but I'm never really satisfied with them; I'm not convinced I've actually made a product that satisfies what the users wanted, even though it technically adheres to most of their requirements (several things usually have to be de-scoped due to lack of time).

I think the main issue for me is the project timescales (which I'm not involved in creating); I don't mind doing all this work but I almost never feel like I have enough time to do it without overtime, which I can't do indefinitely because I'll just burn out (as I have done in the past). Is this normal? Am I just a slow developer? If I am slow, in what ways can I still be an effective worker?

  • We can't really tell you whether you're slow or not, but how common working overtime is and how you should handle being given a deadline that's too short are both probably good questions. Does your (product) manager know how much overtime you're working? Have they specifically asked you to do overtime? I should add that anyone, regardless of how slow or fast, can be given (or take on) more work they can finish without overtime. That really doesn't say much about your ability. Commented Aug 10, 2020 at 20:00
  • 5
    Thanks for these comments; it's making me think that it's definitely worth making more realistic time estimates and not trying to cram them into a compressed timescale so that the project looks normal and keeps the PM happy. Always underestimating tasks makes me feel pressured when they inevitably take longer. So I think from now on, I'll make realistic, maybe even slightly inflated estimates, even if it reveals the unrealistic project expectations. That's not my problem; I can only do so much in the given amount of time without indefinite overtime and burnout.
    – Touchdown
    Commented Aug 11, 2020 at 7:35
  • 1
    @DaveyDaveDave you're totally right, I've experienced the same exact thing. It's just easy for me to fall into the mindset of "Well, I can stay a little longer and finish this one thing..." It's a bad habit that I'm working on being more disciplined about.
    – Touchdown
    Commented Aug 11, 2020 at 7:39

11 Answers 11


I could tell you "yes/no this is/n't reasonable", but who says I'm not either a slow developer myself or of the same opinion as your manager? These things are very subjective and hard to label objectively.

However, there are concrete limits you're up against.

Working hours, for one. Is your overtime being paid? Because if it isn't, yet it is (implicitly) required, that's a huge red flag

I almost never feel like I have enough time to do it without overtime, which I can't do indefinitely because I'll just burn out (as I have done in the past). Is this normal? Am I just a slow developer?

EVEN IF (and that's a big IF) you were truly a slow developer, no one should force themselves to burn out repeatedly or take on tasks they can't handle.

Regardless of whether the company applies more-than-reasonable pressure or you can only cope with less-than-reasonable pressure, you have to take care of yourself and your needs. Not everyone can handle every situation, and that's perfectly okay.

I'm mentioning this not because I think you're at fault or incapable (because I think the company is at fault here, more on that later).
I'm mentioning this because there's an underlying tone of you taking on things that actively damage your mental health and your quality of life for the benefit of the company, which is never healthy.

There's also the generic trope of management who maximize profits beyond reasonable bounds. This comes in two variations: those who lower the output quality, and those who increase pressure on the staff by overworking and/or underpaying them.

It seems like you're dealing with both. Management is not allow any time for proper development practices as you've listed, thus not allowing for the appropriate work to be done, while at the same time overloading its staff by getting them to perform more work than they reasonably can do in the hours they're contracted for.

I can't tell you what to do, but from experience these kinds of situations are hard if not impossible to solve from the position of the employee. The driver of the car has control to steer the car into a wall if they so choose, and management is similarly capable of making bad business decisions and sticking by them. I'm not saying it's good, or that we should stand idly by, but when push comes to shove an employee cannot tell their manager how to manage their company - even if it's being managed badly.

It's possible that management are simply misguided and will listen when the problems are being explained to them, but IMHO (and experience) the odds of that are very little. Management has already proven to prioritize profits over staff quality of life, and (sadly) few people would give up profits to improve other people's convenience.

This next part is purely subjective and anecdotal.

You've hit on many, many red flags that I've encountered before.

  • Business that applies neverending pressure on its staff
  • No interest in staff quality of life or anything else that doesn't net a direct financial profit
  • Profits and deadlines are all that matters ("several things usually have to be de-scoped due to lack of time")
  • Customer happiness is ignored when it doesn't net direct profits ("[it's not] what the users wanted, even though it technically adheres to most of their requirements")
  • No forward thinking or future planning past the delivery deadline. No documentation, bloated codebases, lack of tooling or easy debugging, ...
  • The leaders don't have the core skills of their own business (i.e. the software development). This can usually be mitigated by asking advice from others with said skills, but in your case that seems to be neglected.
  • "just do as much as you can" being used as the default feedback from team leads indicates that deadlines are being used as pressure-applying tools, as opposed to timelines where you can reasonably expect something to be finished. Even in the best of companies, delays can happen. But based on your description the company is burning out its employees and then getting the employees to cover for the fact that the company burnt them out.

Whether you want to stick around in such a system is your choice. I wouldn't, and I've quit every project for every client where the issues proved to be endemic or willfully perpetuated by profit-driven managers.

You have to make your own choice. I do want to add that you having already burnt out in the past strongly suggests that the situation you're currently in is not good for your health, both mental and physical.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Commented Aug 13, 2020 at 16:29

The most important thing for you to do is to start adjusting your timelines, and padding your estimates.

It sounds to me as if you are giving "sunny day estimates", as we used to call them. Your estimates are assuming everything is going to to plan and without distraction, when it is plain to see just by the description you have given us, that you are working in absolute chaos with nasty surprises lurking behind every corner and lurking in every shadow.

Take the greatest number of days you missed a target by, add five to that, and pad your future estimates by that much. When you start meeting deadlines, you can adjust that number.

"Managing expectations" is more than a buzzword. If you say something will take four days, and you deliver in three, the customer will say "wow, he kicked it into high gear for me", and the customer will be pleased. If it takes the same three days, but you said two, the customer will be angry because you are late.

Also, that gives you some breathing room, in case something unexpected happens, so you don't feel like you are about to burn out.

Your company has set up a chaotic environment, which you can work with, but you cannot apply the standards of an orderly shop to a chaotic one. you need to "price in" the chaos into your estimates.

Also, don't be so hard on yourself. You are neither slow, nor overwhelmed. You just need to adjust your, and your customers expectations by allowing for the additional time you will need.

Also, bring up concerns and delays up to management as soon as you have them. I used to tell my people "Before a deadline it's a concern, after, it is an excuse."

If you start to get push back from management, simply state the truth: You are doing all that you can with the resources provided.

Sometimes I would say to my management "A pint cannot hold a gallon, when it is holding a pint, it is already doing the very best that it can"

  • I like this answer in particular. When you are put under pressure by management for timescales when you don't know enough of the facts you should always give yourself more time. I would further add when asked for timescales that my estimate depends on not hitting any roadblocks. Then if you hit snags which will take more time keep the project team informed, if you are blamed you can say that the project spec you were given before you were asked for the deadlines was incomplete so kindly ask the BA who put it together why.
    – Old Nick
    Commented Aug 11, 2020 at 7:45
  • 5
    Padding the estimates is not always that easy. I started as a junior SW engineer a year ago, and was giving really optimistic deadlines, say 1 month instead of 3-4 months, 1 week instead of 1 month. Now, I am starting to give more realistic estimates, and the non-SW people don't like that at all. The pressure was on me before, because I promised more stuff than I could deliver, now they have to decide if they want me to do A or B. Commented Aug 11, 2020 at 8:22
  • 3
    I'm not sure if he's proposing these estimates, but is rather having them imposed on him by management.
    – nick012000
    Commented Aug 11, 2020 at 11:17
  • 1
    @nick012000 to clarify, I'll be told that there's this new project that we've already bid for and agreed an overall timescale for (without my knowledge). The way the timescales are produced is the PM will ask a senior dev what they feel might be a reasonable amount of time to do the project based on a summary and a quick look at the requirements. This could be, say, 3-4 months. I then get those requirements and am asked to create work items and make time estimates for them. My mistake was that I used to think everything had to fit into this timescale, which usually isn't feasible.
    – Touchdown
    Commented Aug 12, 2020 at 8:18
  • 1
    @Touchdown also, remember that sometimes deadlines/timescales aren't. I nearly killed myself to meet a deadline once, only to find it was a "soft deadline". Commented Aug 12, 2020 at 13:25

Congratulations, you've encountered the project management triangle, often summarised as "good, fast, cheap: choose two" for very good reasons.

You're working for a consultancy, also known as a body shop because they sell the time (bodies) of developers like you to clients. The two points of the triangle that a consultancy implicitly chooses are fast and cheap, because that's what their clients choose.

In other words, if you work at a consultancy, you'll never be permitted to deliver work that is high quality, because that is against their business model. If you try to deliver high-quality work, you'll find yourself railroaded to a dead-end role like support, because you become a liability to the company by taking more time than a dev who doesn't care about quality.

This is never going to change as long as you work for that company (or indeed, any consultancy). Trust me - I worked at one for 8 years (or about 5 years too long).

Therefore, the only answer to your conundrum is "find another job" - difficult in this economic climate, but not impossible. Especially if you can demonstrate you care about code quality - there are development houses run by people who care about that sort of thing. Just don't ever work for a consultancy again.

Really, the question you should be asking yourself is: how long can you afford to stay in a job where you aren't getting the opportunity to practice and learn how do software right? How long can you afford to stay in a job that is actively wearing you down? How long can you afford to stay in a job that will happily fire you at a moment's notice if they can find someone who is more "productive" than you in terms of lines of code emitted?

And be careful if (hopefully when) you do decide to leave. The company will do a lot to try to keep you, because they do understand that a dev who gives a s**t is more useful than a fungible brain-dead code-generating human machine - but they will never be able to deliver on the promises they will make to you regarding improving quality. Again, I've had this experience.

  • Agreed. The best thing to do is, collect all the learnings and experiences and move on to a better job. Commented Aug 12, 2020 at 5:02
  • 2
    I agree with the general sentiment of your answer, but not all consultancies are like this. The ones that are more expensive for their clients and pay more to their developers usually are less like this.
    – CodeCaster
    Commented Aug 12, 2020 at 7:40
  • 5
    As someone who has worked in a consultancy, I can categorically say that every word of this answer is true. If you really want to be appreciated for quality work, you might have to leave - and my advice would be to do it sooner rather than later.
    – Rick
    Commented Aug 12, 2020 at 10:54
  • 1
    This - the incentives in a business are set against a type of a quality-caring developer that the OP clearly is. The only options are leaving, burning-out and leaving, or staying as a burnt-out person. Commented Aug 12, 2020 at 12:13
  • 1
    I guess that's more "choose at most two". Believe me, I saw some management that went "good, fast, cheap: we choose none"
    – Pac0
    Commented Aug 13, 2020 at 10:53

That's one of the reasons I'm leaving my current company. But let's come to you, from the client where I am, I've often been put in a project after meetings to decide features and development time, so many times I'd get an email with "Hey, you have to do this thing by June 10th" (usually followed by "WT* is this?") and I also have other projects to work on I always end up working extra hours that no one will ever pay me.

One day after the third time this happened, I took my direct supervisors, let's call them project managers and in a meeting I kindly asked "Please before giving development time to clients, let's talk about it because it's not only a matter of doing something but also of managing priorities and avoiding cross-delivery days", from that day on things went a bit better.

So my advice is to make a very clear and concise speech with your project managers and make them understand that it's YOU who give a development schedule, not them as they are never involved.

  • 1
    To expand on this slightly: the development schedule should be based on a mix of what the product manager (and client) wants, and what's possible - which is an estimate that should come entirely from the dev team.
    – Luke
    Commented Aug 12, 2020 at 4:23
  • 1
    Thing is, while talking to supervisors is always worth a try, it fails more often than it works. If it fails, changing jobs is usually the only viable option.
    – toolforger
    Commented Aug 12, 2020 at 7:53
  • Yeah, that's right. Basically what needs to happen is: 1. The PM doesn't have to say yes to everything the client wants without confronting the developers. 2. Developers should be included in the features discussion with the customer in order to give an exact time frame and a better product at the end of development. If you have groups that don't collaborate properly it just gets confusing and I generally don't appreciate the non-technical filter that a PM might implement when passing the request to me.
    – Skelethos
    Commented Aug 12, 2020 at 8:19
  • 1
    As you are seeing, this only works in a healthy environment. The OP's seems to be SOP to not care about their devs, only money and deadlines. It's probable the CxO's want to get a rep of "doing anything quickly and cheaply" so they can rake in more business. Unfortunately, this isn't healthy at all, which you and the OP are seeing. If it's too bad, the OP, like you, won't be able to change the mgmts minds, so leaving may be the only option. Commented Aug 12, 2020 at 19:00
  • Yes, I know, but trying the road of friendly communication and pointing out the problems that this management is bringing should stir things up a bit. Of course, if after this meeting things don't change, OP looks for a new job, run away! :)
    – Skelethos
    Commented Aug 13, 2020 at 6:02

To answer whether you're slow or overloaded, talk to your team mates. See if they agree with your estimates and whether they also need to do unpaid overtime to meet their timelines. If you all agree that a task should take a week but the boss wants it done in 3 days, he's not going to fire you for taking a week because any replacement would take at least a week to do the same task.

You can also look at whether the company has difficulty recruiting and retaining staff.

In the unlikely event that you find that you really are slow compared to others of the same experience, work out which parts of the job you do faster or better than them, and see if you can move sideways to sales/project management/testing or whatever suits you.

In the much more likely case that the company is sacrificing your health and free time for their profits, interpret "do what you can" as "do what you can in the time we pay you, and leave the problem to the salesman who underquoted in order to win a contract that wasn't profitable".

There's no need to be militant about leaving on time, especially if it would cause a problem for a colleague, but (unlike the directors) you don't have equity in the company and don't benefit from your extra hours.

  • 3
    I did this and found that this is actually quite common across the devs, even the senior ones; one even said it was "absolutely bonkers." It's reassuring to know it's not just me after all. It just seems to be the (grudgingly?) accepted development approach in the company.
    – Touchdown
    Commented Aug 11, 2020 at 16:50
  • 1
    Managers will absolutely fire you if you can't manage their unrealistic time frames. They think they'll be able to find someone better, faster, and cheaper who can just walk into the job without training on the SOP or code base. I've been on both sides of that, much to my detriment both ways. And the sales person is "never wrong", it's "always" the dev that can't deliver what someone else promised. It's BS, but it's how many businesses operate. Been there, done that, don't want to go there again. Commented Aug 12, 2020 at 19:05
  • 1
    @computercarguy - what happened after they fired someone and were unable to recruit someone faster? Commented Aug 13, 2020 at 8:11
  • @RobinBennett, I don't know. I never tried to find out. I figured that if they didn't care about me while I worked there, I wouldn't care about them after I left. Ok, so I did hear about 1 place, years later, that after I left, a whole bunch of other people left for the same reason. And I guess there's that other place that replaced me with a couple of off-shore devs. I'm sure many of the "temp-to-hire" places still haven't hired, since that's usually a farce, and not just me talking here. I've heard from recruiters that the "to-hire" part is just to get more applicants. Commented Aug 13, 2020 at 16:00

Because we're such a small company, we have to:

  1. Take whatever work we can get, and
  2. Be as cheap as possible

The way we stay cheap is to basically compress development into as short a timespan as possible.

So your company was able to have the trifecta of effinency (quality, managment or whatever it's called)? People, time and money OR Fast, cheap and good (where you can only select two).

If you are cheap, and have small amout of people to do the work by proxy. You need put emphasis on time. You think something take 10 hours? Write down 15 or even 17.

I once did an experiment. I wrote down how much time I really spend on doing something. Not just doing it but stopping working on something else, checking, looking, saving, going back to my previous work and being exactly where I left. 2 minutes B job became 30 minutes not doing A job.

Now, as you realized, that a hit on you. Because your company don't have the trifecta. It's paying the time/budget debt with you. You're doing the overtime, you're spending time to catch up with documentations or blocks while thinking YOU are borrowing time from the whole project.

First issue you need to face is that company sees that as YOUR problem. The product is cheap and on time. So there is no issue with delaying or moving deadlines. You also don't have a time stamp "look, this issue taken us 5 days so we had to push deadline 6 days".

You can count the overtime. It's measurable. But you cannot measure how much you strain yourself during the whole week. You might be doing 2 hours extra on top of your 8. But you might squeeze 15 hours in there. No brakes, no checking, no reapiting, cutting corners on writing documentations etc.

So if you take Project Time and add overtime it will be 75% of real time needed to deliver the product. Product you will be satisfied with, with good overall quality, docs etc.

Doing as much as you can shouldn't be interpreted as "Do as much as you can in this time". IT should be "Do only things you CAN and do only things you can fit in give timeslot".


You could be both at the same time. For your speed of work (which not only depends on your performance/skills/motivation but also type of tasks and quality of preparation) you have too many tasks.

All you can do is to assume it's overload and improve the situation (rejecting, more efficient processing, give feedback to reduce redo, etc). The question if you are too slow or not will be noticed by your peers and manager - relative to the other staff. Just make sure they have the full picture (are thorough, friendly, helpful, dependable or produce less need for rework, then make sure this is factored in).


Ask your boss to prioritize items, so that you can drop less-necessary items when you run out of time.

While nobody else has mentioned this, "just do as much as you can" is an important part of the Agile process. Basically, when a project starts running into time and cost constraints, there are two possible solutions: the first is to increase the time and cost of the project in order to finish everything (the Waterfall solution). The second is to drop less-critical parts of the project so that you can ship a Minimum Viable Product at the deadline: the Agile approach.

As such, it's important if your boss asks you to just "do as much as you can" to get them to prioritize which parts of the project are most important, so that you can get them done first. Then, at the end, you've done as much as you can, and whatever you didn't get done in the time available just didn't get done.

A common tool used for this sort of prioritisation in Agile is MoSCoW: Must Do, Should Do, Could Do, and Won’t Do. You should avoid allocating more than 60% of your Story Point items to Must to avoid losing flexibility.

Having gotten buy-in from your boss on this, it can also help free you from the feeling that you need to work overtime to get everything done, because you don't need to get everything done. You only need to get as much done as you can, in your normal work time.

  • Thanks, this is a good answer and something I'll raise with my manager. I think my company doesn't make it clear exactly how much responsibility devs have; the Agile process isn't explained, we're only told: "Here's what we've got to get done by this deadline." So in a way it seems like we're being told to be Agile, but expected to deliver Waterfall.
    – Touchdown
    Commented Aug 13, 2020 at 9:08
  • @Touchdown A common tool used for this sort of prioritisation in Agile is MoSCoW: Must Do, Should Do, Could Do, and Won’t Do. You should avoid allocating more than 60% of your Story Point items to Must to avoid losing flexibility.
    – nick012000
    Commented Aug 13, 2020 at 10:05

Welcome to software development! Every single developer has this same experience. Your only problems are estimation and work/life balance, not "slowness".

That you are slow is just what your project manager wants you to believe. Focus on accurate estimation, not "being faster". That way, if your estimate does not line up with the artificial deadline, you can have the tough conversations about scope and expectations very early in the project, rather than very late. And don't allow yourself to be pressured into overtime week after week. If you do that, you will inevitably burn out and you will be miserable and less productive.

  • How do you know OP isn't slow? There is a lot of variability in the productivity of programmers.
    – Alex
    Commented Aug 12, 2020 at 12:24
  • 1
    It really doesn't matter if OP is slow or not. The problem is that the expectation on his productivity exceeds his actual productivity. In Lean Manufacturing this is called Overburdening and is a form of inefficiency in the organization. A junior developer might be much slower than a senior dev, but he's not going to get faster overnight by wishing it. I perceive his actual problem is expectation setting and estimation, not performance. If he is really not performing, but estimating accurately, then management can bring in more team members or reassign work before it becomes a crisis.
    – wberry
    Commented Aug 12, 2020 at 15:40

usually put on projects either solo or in a very small team

Next time this happens see how does your performance compares to rest of the team? If it takes you 2 weeks to finish 3 day estimate see if other engs also make similar estimate mistakes. When they develop a feature go through their code and try to see how long would it taken you to do it and compare it to their time.

Since you are relatively new it is fine if you are at 60-70% of productivity of seniors, but if you are at 20-30% that is not good.


Unfortunately a lot of contract work is like this. The most common "solution" is to implement exactly and only what the spec requires. Testing is limited to the precise way in which the spec says that the software will be used. Forget doing a good job, fulfil the contract and no more.

As an example some software that was contracted out a few years ago came my way to test. I noticed that if you entered more than 20 characters in one of the input fields it would crash. When I queried it they came back with a quote to change the spec and add additional testing, because originally my company didn't specify "must not crash if you enter more than 20 characters".

It sucks, most people hate doing a bad job when they know they can do better, but it's what your client wants. If they wanted more they would specify more and pay more.

The good news is that with 3 years experience in a selection of different technologies you had to learn you are in a great position to find a better mid-level developer job.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .