Am I overloaded or just slow?

Question

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?

Answer 1

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.

Answer 2

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"

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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".

Answer 7

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).

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.