I'm doing 90% maintenance and 10% development, is this normal? [closed]

Question

I have just recently started my career as a web developer for a medium sized company. As soon as I started I got the task of expanding an existing application (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure).

So after I had successfully extended this application with the requested functionality, they gave me the task to fully maintain the application. This was of course not a problem, or so I thought. But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported.

From then on I have had three more projects just like the above, that I now also have to maintain. And I got four projects where I was allowed to create the application from scratch, and I have to maintain those as well.

At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. They expect me to handle these mails directly while also working on two other new projects (and there are already five more projects lined up after those). The sad thing is I have yet to receive a bug report on anything that I have coded myself. For that I have only received the occasional let's-do-things-180-degrees-different change requests.

Anyway, is this normal? In my opinion I'm doing the work equivalent of a whole team of developers.

Was I an idiot when I initially expected things to be different?

I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

P.S. My salary is almost equal if not lower than that of a cashier at a supermarket.

Answer 1

During one of my internships I found I spent a lot of time doing bug fixes. You have to realize that as an entry level employee you aren't going to get the sexiest work, you're going to get the grunt work no one else wants. It's unfortunate, but it's how it is at every job.

Additionally, you have to realize that to a company, having code that works is more important than having code that is clean. From your company's perspective, you changing the existing structure is money wasted on redoing something that is already done and potentally introducing even more errors. Usually these types of companies aren't computer/software companies so no sufficiently high manager has the technical background to know that sometimes you need to do these major overhauls. That said, if your company is run by technically competent people and they understand the value of good code, you may get more leeway, although sometimes you need to choose your battles (the main purpose of a business is still to make money, after all).

That said, you are not unreasonable in wanting to be able to leave your mark on the software and wanting more meaningful work. It is also unfortunate that you have to deal with so many projects at once while fielding requests from so many different managers.

As a programmer, it is a fact of life that you will spend more time maintaining and modifying other people's code than you will writing your own from scratch. If this is a problem for you then perhaps you should stick to developing as a hobby and pursue a different career. If you are OK with maintaining code, but you feel you are not being used effectively or are being overwhelmed, then that is a matter you need to discuss with your manager. If your problems are more serious than that or if you feel like your managers don't know how to effectively manage your skill set then it would be a good idea to consider finding a position at a different company. Given your stated low salary, this is probably your best course of action.

Answer 2

It sounds like management has a problem managing your workload and prioritizing tasks. You should talk to your manager and make them understand that you are overloaded and you can't do effective work if everyone keeps bombarding you with requests which they want fulfilled immediately.

That makes you jump from one task and project to another, wasting a lot of time switching gears in your mind. For effective software development work, one should be able to immerse oneself into a task and focus fully on it. The more interruptions one gets, the more time is wasted by context switching. Research shows that it takes about 15 minutes to immerse and get to the state of flow where our mind works the most efficiently. If you get interruptions every 15 minutes, you never get to flow, which is a tremendous waste for both you and the company.

So you should try to negotiate a more sensible working mode with your manager. This should include prioritizing the incoming requests and planning ahead to some extent. All user requests should be maintained in a list, ordered by priorities. And the priorities should not be decided by the requester (as naturally everyone thinks his/her request is the most important on earth), neither by you, but by someone with enough business knowledge and overview of the whole range of products you are maintaining (the product owner).

Ideally, all incoming requests should be entered into an issue tracker like JIRA or Mantis. Or at least mailed to the product owner, not you. And he/she should deal with all the complaints from the users too over "why is my request not ready yet?!", allowing you to focus on the development work. If this is unattainable, you should at least negotiate some windows of time when you look at incoming requests and deal with them, reserving an uninterruptible portion of your time solely for development.

If this is possible, the next step could be to plan ahead to some extent. That is, estimate the time needed to implement the top priority requests, then schedule your time into sprints, which may be one or more weeks each, and allocate enough tasks to the next sprint to cover your time.

You probably want to keep a portion of your time for incoming emergency requests, but the rest can be planned ahead. And you may also prefer to organize work on different projects into separate "streaks", that is, to work on project A on Monday, project B on Tueday-Wednesday, project C on Thursday morning and D on afternoon, etc., to further reduce context switching.

This way you have a rough idea of what you are to do in the next one or few weeks. Moreover, this gives a roadmap to your clients too: they can see when they get which request implemented. You may or may not want to mention the word "agile" to your manager here - this is basically agile development, but some people oppose agile without actually knowing what it is :-)

Note that even if your current position seems low valued by your company, the more projects you are maintaining, the more negotiating power you have.

Finding and training a new hire to maintain all these projects takes considerable time ( = money) for the company. And you may rightly point out that your code is so much better than the legacy parts of these applications, so it is not a given that they can easily find a candidate of similar capabilities for the same amount of money. Not to mention that if they don't improve working conditions, they will make the next guy get fed up and quit just as fast as you... Try to make them understand that it is in their own best interest to keep you, and to keep you happy where you are :-) This may give you some power to negotiate the above conditions, and/or request a pay raise.

How much negotiating power you have - that is a big question. Your management may or may not be open to these ideas, and may or may not respect you enough to take your pleas seriously. But if you play your cards well, you have a chance. And if they refuse... you can always look for a better workplace. This situation isn't the same for every starter, although (sadly) your experiences are fairly typical. But there really are better workplaces out there. The quality of workplace is only loosely correlated with geographical location, but my feeling is that in Northern Europe you have higher than average chances. So if you can't get your current conditions noticeably improved, you should start looking immediately, before you get completely fed up, and burnt out.

It is immensely better to look for a job while you still have one, so you need not accept the first offer just because you need money immediately. Eventually you will find a better place :-)

Answer 3

P.S. My salary is almost equal if not lower then that of a cashier at a supermarket.

Heh I wanted to write something about how to negotiate until I read that. Now all I can say is leave! Assuming that's half of what a developer with a degree usually earns. And assuming that things improve and they give you immediately a 10% increase you can figure out yourself how long it takes to get there. It also looks like you do not learn anything on the job and you don't seem to be surrounded by brilliant engineers there, so it's a waste of time.

Answer 4

I was also in a similar situation, and I can tell you that if you stay on that track it never ends. Management will keep shoveling it at you, because... they can.

There are a few additional thoughts that I have on this topic.

1. Do what you love. If you don't love it, prepare yourself for making the attempt to find what it is that you might love.

2. Communication. Communicate clearly your inabilities to deliver to unrealistic expectations. In my similar experience the architect (who did the most shoveling) said, "you have to manage others expectations of you."

3. Burnout. If you have not experienced burnout, do not tempt fate. It sucks your life and soul out of your mind. Despite your best effort, your working purpose becomes grey, dreary and meaningless. I impart this advice because you must, at all costs, avoid burnout.

4. Training. Here is the silver lining. Your training and experience, while frustrating, and perhaps underpaid, is in fact, very valuable to your career. This is your saving grace to realize this because you can soak up as much learning as possible and delay any inevitable glass ceiling.

Focus on what talents and skills you are growing... These will carry you through the next opportunities of your career.

Answer 5

You're dealing with multiple issues here... Let's start with the obvious...

Is This Normal?

Hell no. But... is it common? Unfortunately, yes.

Regarding Bug-Fixing Frustration

While that doesn't excuse the rest of the mess you have to deal with and the multiple projects they overload you with, I just want to make a quick note that the "bug-fix" only approach, while frustrating for you as a developer, can be a perfectly sensible approach for the company and its management.

Surface for More Bugs and Costs

The more code you touch, the more likely you are to introduce bugs, even if your intent is to improve it. That means extended dev time, test time, and costs. And if it slips through to a service release with a medium to high-defect, that's a big mess for them.

Noise / Fog in your Logs

From an SCM-perspective, it also makes a bit of sense if you work directly off a service release's branch, as you want to have a clean view of changes relating to bugfixing. If there are 15 commits with thousands of changes surrounding a bugfix that actually required maybe a 1 line code change, it's a tad annoying.

So, being a new hire, it's even more sensible to ask you to refrain from refactoring and/or enhancing the software, and quite OK in my sense to be as "surgical" as possible with your bugfixes. It just keeps headaches at bay.

Can You do Something About It?

Now, it does NOT mean that there would be ways of achieving both sanity of the code and sanity of the involved people's minds. Being junior, they should have someone review your changes, especially bugfixes, and make sure they are approved before making it to the service release builds. That would prevent or limit radical changes, and be safer.

The Project From Hell

Crap Code, Herd of Programmers, Duplication, Crap Architecture

Again, devil's advocate here, but just showing that your initial request contains a few non-consequential bits.

My point is this: I really really really rarely took over a codebase that wasn't in this state. And on the off-chance that I did, they were recently started projects or prototypes that had been kick-started by pretty stellar programmers. But the astonishingly vast majority of them looked like crap, and a scary number of these were actual crap. Even the ones started by good or great programmers can end up being crap, deadlines and other engagements helping...

Welcome to real-life industrial software engineering!

And you know what's fun? It's often way worse in the web-development world. Enjoy! :)

Too Many Projects & Requests, Not Enough Hands & Time

The problem lies here probably in:

• your management (maybe unconsciously) abusing you,
• your colleagues (maybe unconsciously) abusing you,
• your (maybe unknowingly) not covering your ass and fighting your battles enough.

Your managers should be aware that you are working on too many projects to manage. If they aren't, make sure they are ASAP. Make also sure they know it wasn't all a pick-nick in the park and that you felt pressured, and that it needs to stop.

Try to have a look around and make sure your colleagues do not deflect more tasks and projects on you, directly (by really saying "X will be able to take care of that") or indirectly ("I'm not the right person for this, find someone else" -> ends up being you).

Personal anecdote here: I did an internship a few years back, and just on my very last day, when I got my evaluation, my boss told me, despite being very satisfied with my work overall, that one of the managers had the feeling I had been unloading some "not so fun tasks" on another intern when they would have expected me to pick them up. I was mortified of having them felt let down, and at the idea that I would look like I was slacking off, when my intent was the exact opposite: I was trying to grab the harder tasks and have the other younger intern deal with less hair-pulling issues. Little did I realize that, had I been in his position, I would have been bored by the lack of challenge and probably felt the way he did. The point is, you need to communicate to make sure nobody makes false assumptions about 3 very distinct things:

• what you can do,
• what you want to do,
• and what you are willing to do.

So it's also partly your fault for letting it become this way. But it's normal, it's a lesson everybody needs to learn. It holds in two letters: N - O.

You usually employ it as a prefix for a more lengthy but not so much more charged answer: No, I can't do this. No, I don't know how to do this. No, I'm not sure I'm the right person for this. No, I've never done that.

At first, it's very easy to feel like you can just say "yes, I'll (eventually) do it", and pile things up and get them done, maybe by putting some extra hours in. That's all wrong. You need to understand that your time is, after your skills, your most valuable asset, to you and to your company. If it is misused, it impacts projects, deadlines, and budgets. As simple as that.

Also, it looks a bit worrying that you would have too many people to report to. It's OK to have multiple customers to deal with, and multiple project owners or even principal stakeholders you need to communicate with. But, overall, especially as you're a new hire, you should mostly report to a few managers only (and most likely only your direct manager, and possibly a lead or senior developer). How did it get this way? I don't know. It can be an organizational issue at your company, or it can be the result of you doing a favor and of then being contacted directly, and failing to say "no". Or it can be that your direct manager as issues with dispatching tasks, for all I know (I'm really guessing, but the pattern are recognizable and well-known).

I'd recommend you do the following rather quickly: go talk to your direct manager in person, explain that other managers might be a bit pushy, or (probably less whiny) that you have too many stuff piling on from too many people, and that you need his input (and possibly theirs as well) to know which ones to prioritize.

180-degrees Change Requests

These are another big issue. They're probably not your fault, but you can try to help them address it.

"180-degress change requests", as you beautifully and acurately call them, are a clear sign that requirements are fuzzy from the get go, and that nobody tries hard enough to have them chiseled and cleared up over time.

That's usually when someone needs to get on the phone (or better, on their feet), and grab stakeholders by the hand and tell them clearly: "that's where we are, that's where you want us to go, do you confirm we're heading in the right direction?". It's OK to not get clear answers at the beginning, but the more time passes, the clearer they should become, or this project is a disaster waiting to happen.

Usually I'd say grab all the stakeholders within reach, put them in a room, drive them through litigious issues and incrementally try to resolve these - and get priorities while you're at it. However in your case, this may not be your call to make already. But you mention they really gave you the responsibility of the projects; so if that's really the case, then do take responsibility and do that. And DO NOT shy away from saying "we CAN'T do that", or even "we WON'T do that". It's really important to limit the scope of a project.

If there's no scope, there are no clear-cut requirements at the end of the discussion.

E-mail Overload

People tend to behave differently based on the communication medium they use. Personally, though I'm a rather soft-spoken person (and have been working mostly in foreign countries, so I also end up not liking to talk on the phone to much), I'd favor in order of preference based on productivity:

• talking to people face-to-face,
• talking to people on the phone,
• talking to people via IM,
• talking to people via email.

E-Mails are nice for tracking, for getting confirmations, for sending notes.

For scheduling, planning and discussing problematic points, they're close to useless. Go knock on the guy's door until he/she opens it and sit down with a notepad and a copy of your documentation to clarify things. Once you're done, then send an email and ask for confirmation. If it comes back with a negative answer or a slightly hidden attempt at sneaking something else in the envelope, go make the siege of your interlocutor's office again.

This is software engineering. It's often more productive when you don't type away on a keyboard, and can actually cut down upfront on the crap you'll need to deal with.

Doing a Team's Worth of Work

Are you doing the equivalent of a team's worth of work? Maybe.

Are you doing the equivalent of your team's worth of work? Probably not.

What I mean is that your team is probably busy working, and you are overworked. And that's the issue: you're overloaded with things that should be pushed out of the current project timelines, or given to someone with time on their hands.

Was I an idiot when I initially expected things to be different?

No; just new to the party. It's like a first hung-over or relationship. You'll get over it.

I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

This is the same for every developer in chaotic organizations, be them startups or well-established giants, and with no experience or confidence to get things to move one bit to tip your chances of survival on the right side of the scale.

P.S. My salary is almost equal if not lower then that of a cashier at a supermarket.

I did decent salaries on jobs that would appear crappy. It's not the number on the check that counts, it's the context. What you do, your age, where you live and work, etc...

That being said, if you are grossly underpaid, working too much, and not entirely junior, go ask for that raise or get a new job!

It's simple:

• if they value what you do, they'll gladly agree to a raise,
• if they don't, future in this company doesn't look very rosy (for you, at least, which is what matters), so don't feel bad about leaving.

Be aware that asking for a raise is a good thing, even though you wouldn't be enclined to think so at first. It proves you keep track of what you do, and hints that you keep an eye on other option while still being willing to stay onboard. And it's a good thing to get used to request them, as they are like job interviews or bargaining in general: it's something that requires practice, and they don't fall from the sky if you don't reach for them yourself. Some companies will distribute raises regularly without being requested to, but that's only because they are clever enough to know that it keeps you half-happy and less willing to change, and they want to cut the grass under your foot (most people would feel a bit uneasy about upping a raise offer they've been offered directly).

How to proceed with this request is a bit out of the scope of THIS project right here, so I won't go into the details. But I'd recommend you prepare a record of your SCM commit IDs, of your fixed bugs and achievements, and that you also prepare reports comparing them to the team's overall effort. This way:

• you can measure for yourself if you effectively did a lot more than your peers or not,
• you can stand your ground if they say your request is not justified.

Answer 6

In addition to other people's comments:

1. Yes, it is normal for an entry level employee to be given the jobs nobody else wants to do.

2. You should see this as a building block for your future career.

So what should you do? In order to prove youself as a professional developer you need to ensure your work is structured and planned, otherwise you may find it hard to build on the good things you're currently doing - so you should try to do things like the following (if you're not already).

1. Log your work accurately, for each project. So if you spend one hour fixing a bug on project A, log this time. This will be useful to show to your manager if you want to discuss workloads.

2. Write unit tests. You mention some of the projects you maintain are full of bugs, so my guess is that there are few (if any) unit tests. For each bug report, write a unit test which replicates the bug, then fix the bug. This will help ensure no regressions occur, improve the quality of the code, and serve as a platform on which to refactor the code if you're given the chance (for example, it could help you convince the stakeholders that rewriting some parts could improve quality without introducing new bugs, due to the unit test suite).

3. Look for a new job - you work on many projects at once, you have written code from scratch, and you have probably experienced the entire project lifecycle - these are all good experiences for applying elsewhere.

Answer 7

Your situation is a bit edgy, yet still normal. But the way you handle it is very bad. Here is what you need to do:

• Try to confront your boss. You should have some proof (numbers) of how much time the bad code base actually costs. If he does not understand stuff like technical debt, stop mentioning it. It would wreck your head, and you could be marked as a 'bad attitude' guy. It is not your job to teach your boss to do his work.

• Maintain your own backlog (kanban). When new tasks comes put it at end, and tell estimated time of completion.

• Increase your response time, check your email only twice day. Typically before lunch and just before you leave. (Checking email should not be followed by coding, as it may wreck your head).

• Make small code improvement as part of each task. It is simply your job to improve code, skills and tools you are using. It will also boost your moral in the long term.

• No project switching during the day. Today you are simply working on project X, and you will start other task for Y tomorrow.

• Allocate one hour per day for gate keeping. It means small tasks which are trivial to do. If this task takes longer than 10 minutes (no mater what the reason is), it goes into the backlog and you notify the manager it will be delayed.

Now comes the hard part. Currently managers do not communicate with each other, and just assume you will finish their own project with maximal priority. This brings a lot of stress on your head, because you are in middle of arguments. You need to force managers to start coordinating your work. At the end you should have a nice & simple backlog and managers should bully each other without you.

So let's do some simple role playing. There are three managers and projects (Xavier with project X, Yvonne with project Y and Zed with project Z). You have a backlog for two weeks, 5 days for X and 5 days for Y.

• Z asks you to do some task (1 day)
• You respond that it will be done in 11 days.
• Z responds that it is simple task and should not take more then one day (notice that Z applies small pressure).
• You respond that you are currently working for X and latter for Z. You can do her work after that.
• Z responds you should do his task immediately anyway (increased pressure, direct violation of X and Y territory).
• You respond that doing her task would delay work for X and Y. He should ask them first. You also CC X and Y.

Now there are two ends:

• Managers will start barking at each other, many emails, probably some meetings... You should stay away and let the winner assign you a task.

• Nothing will happen, Z will ask you two days latter where his task is. You answer that you are working for X currently, and he did not mention anything about project Z. Again CC X.

Now this type of behaviour can get you fired. But your situation is unsustainable, and you will probably quit soon anyway. This solution only works if managers are competing against each other (very usual). You should also keep records of your work (backlog), in case somebody would complain, that you are slacking off.

Answer 8

Seven years ago I was doing pretty much 100% maintenance work for a while and wrote an article about it: The Art of Maintenance Programming. One part you may find useful:

1. Get to Like It

How can anyone like maintenance programming? Developers dream of being chief architects in their teams, and when they end up maintaining existing software, it feels almost like punishment. It doesn’t have to be: maintenance programming has its own set of challenges, and requires a lot of creativity, adaptability, patience, discipline, and good communication. It can be good for your career as well: having bombastic entries like “Architected n-tier 24/7 enterprise application” in your resume looks nice, but employers actually value people who solve problems; and maintenance programming can be a good chance to demonstrate your problem-solving skills.

Answer 9

Your problem sounds like sommething you hear more often about. It appears to be a job that could easily fit on The Daily WTF.

A lot of organisations focus more on sales or feature pushing than on quality. What those companies fail to see is that there is more than external qualities of a piece of software. Ward Cunningham coined the term technical debt.

You might also want to read Steve McConnell on technical debt. He has some interesting points. In a Google Tech Talk, Ken Swaber talks about agile software development. A good part is about a story similar to yours. He talks about a software project that has become "braindead" after 10 years of programming by various programmers without ever doing any refactoring. I think that if you see this video you'll see a lot of similarities to what you describe.

Any software system will degrade in quality when it is being expanded on. In fact in order to survice it will have to. The Lehman Laws explain this principle quite well. Ultimately it will boil down to the following question: "How do I convince your boss to do refactoring?".

How I approached a similar problem:

• I confronted my boss and explained that code quality degrades when we keep developing (Lehman Laws).
• I tried to explain my boss the concept of technical debt. And that the way he lets you to work is a way that will cost him money in the long run.
• In order to actually show him how severe the problem was, I have (in my own time) done a static code analysis. Bosses don't understand software, but they understand numbers. Although code metrics have their flaws it is good to have something measurable you can talk about. Try to find out what normal readings are for these metrics, and you will be surprised when you compare this to your own codebase.
• If nothing helps and nothing changes, the only thing you can do is explain that a certain new feature will require some rework of other parts of your codebase. Explain that if you have duplicate code and they want to change something that the costs of a change duplicate as well.
• A common answer to the previous point will be that no-one has asked and thus not paid for this rework. That "perhaps" this rework is superfluous. You will have to explain that software will always have to change. Like the Lehman Laws say; it will have to change in order to remain in use. If not, other programs who did change will always outlive. It is those who expect change and can adapt to change that will survive. This is what agile software development is all about. (Wikipedia)

My boss nowadays uses the concept of technical debt to explain to our customers that we sometimes need to rework parts of the software we build. Just to prove that - if you have a reasonable boss, it is possible to change things for the better.

Answer 10

The situation you are facing is nearly (if not totally) the same for many freshers.

This happens in the initial phases of a career. Here is the catch: We have to overcome this issue and prove our value to the company (be it medium-sized or MNC). We should be able to make decisions about what the circumstances demand us to do. So there is nothing harm in putting efforts in the job, provided you get noticed for it and stand as an individual for your work. If you are worth, the company will notice! Adios and best of luck.

Answer 11

In my opinion, a company that prohibits refactoring is not worth working for. Refactoring is an essential software development skill, and version control tools make it very easy to develop changes in isolation without corrupting the 'trunk' (in case a refactor actually does break something). As Uncle Bob says (paraphrased): "You should haven't to ask to be a professional and do your job right."

Maintenance programming should never mean perpetuating bad code.

Answer 12

I have received this email five years ago from one of my friend.

Email body:    

A newly joined trainee engineer asks his boss "what is the meaning of Appraisal?"

Boss: "Do you know the meaning of resignation?"

Trainee: "Yes I do"

Boss: "So let me make you understand what an appraisal is by comparing it with resignation"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Trainee: "Yes boss enough, now I understood my future. For an appraisal I will have to resign ... !!!"

Answer 13

If I were you, I would spend some late hours after work rebuilding the application for free. It would probably be a fun task. When you finish it, show it to your boss. If it works and you're doing maintenance on it, he should have nothing to worry about. This will make your job much easier and would open the eyes of the higher ups to your potential in the company.

I'm a full time college student working a part time internship for US$10 an hour. I do QA stuff that's boring, repetitive, and easy. I consider myself to be extremely lucky, because I know one day this will open doors to bigger and better places.

Answer 14

Yes, you will always have to maintain applications, written both by you and other people. The only exception is if you write a program which never, ever needs any maintenance. So you better get good at maintenance.

I think there is a subtle hint in your question of a flaw in your approach. That is, that fixing bugs does not involve improving code.

But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported.

I can't believe someone has told you "you must fix bugs without improving the code." This is both difficult and impossible. What you can't do is re-write the application just because you don't like, or find it hard to understand, the approach used in the existing code-base.

My advice is to learn to refactor. Any time you are fixing a bug, you have an opportunity to improve at least some of the code. How much of the code-base gets refactored depends on what the bug is and how good or bad the code is. But if you're fixing bugs and knowingly leaving code smells all over the place, then you're not doing your job and you're building up technical debt.

Some bugs are actually fixed simply by refactoring, and sometimes it's useful to refactor in order to help you understand code. This is because refactoring ought to improve maintainability and coherence of the code.

When I estimate a bug fix, I will usually make a decision about whether a major refactor will be the best way to do it, and take that into account. The same with unit tests. Both these things should be part of the way you write code, not something optional which involves extra time.

So you shouldn't be asking "can I improve the code when I fix the bug?" Because you should be anyway. You shouldn't be asking "can I use refactoring to fix the bug?" Because if the code which is causing the application to bug out is in dire need of refactoring, you should do it anyway. You shouldn't be asking "can I write unit tests when I fix this bug?" Because you should write a regression test before you even start trying to fix the bug.

NB: I feel some attribution for this answer should go to Jeff Atwood, seeing as I linked 3 of his articles.

Answer 15

This one is all about money. My guess is that as a starter, you are probably too kind for customers who've already gotten more than they paid for.

Learn to quote a price for new requests. This is far from easy and customers will often try you out. If you can, enlist the help of an experienced project/product manager.

Once you think in terms of money, communicating with management becomes a lot easier. If your current customers provide full time money, you should not pick up new projects. But you'll understand that management will still try to bully you into doing them.

If you are indeed valuable to the company, you'll gain bargaining power. You can ask them to hire more people, get fewer new projects, help you reduce maintenance load, or increase your salary.

Answer 16

It should not be the decision of your employer to micromanage you to the extent, that you are prohibited from improving the existing code. Use your own professional judgement. When you are estimating work, I would factor in additional time to allow for some refactoring, if it will increase productivity in the future.

Anyway, it seems like you aren't effectively communicating with your employer.

1. You have evidence that refactoring will save money. Draft a proposal for a refactoring project and demonstrate how much time and money the business could save. Outline precisely what changes you would make to the code, and how long it would take.

2. Keep an accurate log to record how much time you spend on coding, meetings, and answering emails. This will protect you if you fall behind schedule.

3. Slow down. This may seem a little counter intuitive, but your time will only be abused if you do everything quickly. People will respect your time more if you do less. For example, I would only check email once or twice per day. Otherwise, you risk burnout.

4. Considering your pay rate, it isn't worth getting a headache over. Make sure you leave on time every day. Don't put in extra hours without additional compensation. The exception is if there are good advancement options, or if the reputation of the company will greatly boost your resume, then you will just have to suck it up.

Without knowing more, I would just suggest that you try to be more open with your managers. Maybe start increasing your task estimates. Constantly remind them about how busy your workload is. Also, you should meet with your boss and explain that you would like a salary increase within the next six months, and ask how you could improve your performance in order to achieve this pay increase.

Good luck.

Answer 17

In my experience the academic world or the first 6-12 months of a tech-oriented start-up are the only two reliable areas where you'll encounter a true blank slate. They both carry their own costs but if you love to code and are often horrified by the quality of the code you find out in the wild, you should start pointing your career in one of these directions.

Answer 18

Try talking with your employers and see if you can solve this out. It sounds like you're way over your head on this, and it has nothing to do with being a bad programmer.

Smaller web companies tend to have a lot of projects going on at the same time, which in many ways leaves you in a though spot. Either try to make the best of your situation, or try to find a new job if you think you can. I promise there are better coding jobs out there, so don't let this first one scare you off.

Good luck, and I hope both you and your co-workers understand the gravity or your efforts!

Personal experience

Like many here I also recognize your situation. I basically got my first coding job with a low salary and had to maintain a lot of built code with a poor structure. At first I found it funny to learn new stuff, but when I in the end had lots of projects to maintain, new projects to make and a white board which grew bigger and bigger every day with points I wasn't done with I realized that it wasn't working.

After putting up with it for two years, I quit and found another coding job a couple of months later which fits me perfectly.

Anyway, many times it's not only your projects that might be the issue. I find myself more comfortable on a workplace when I get acknowledged and respected for my work. The problem with the situation that you're in is that your employers might only notice the bugs which arise from created projects, and not the time you take to remove all the other bugs.

Salary

If you want more money, you can often get it. I managed to negotiate my salary in under two years to a raise of 33%.

Basically, think about the value of your work and how much the company needs you. If they can't afford to give you the salary you've earned, then the company either needs to looks at their expenses or realize that their business isn't working.

And as mentioned by many here, and I agree, you're a very valueable piece of the company puzzle. Hell, you're probably the only one that can solve that puzzle. :)

Answer 19

Since I can't comment yet because I'm a lurker on this Stack Exchange site, I will just add to the information on here.

1. Since you are just starting out, your salary isn't going to be stellar unless you went to work for a big company like Microsoft, Amazon or something akin. But it shouldn't be that of a grocery employee! Don't put up with that for long, gain experience doing what you are doing and move on when a better opportunity arises.

2. For an entry level gig this is kind of normal. Your workload is too high, but the type of work is expected. To become a better developer you must learn from others' mistakes. The more you see, the better you become. But that implies you are looking for things to learn from, not learning bad habits...

3. The ratio of maintenance to project work should shift over time. If it isn't, that means the company you work for doesn't realize how to keep a good developer; they intend to have you do the same thing day in and day out. Make a yearly goal for yourself as to where you would like to be, salary and job expectations wise, and move accordingly.

4) If you aren't happy, leave! Life is too short to deal with stupid people.

All the best.

Answer 20

You start using an issue tracker to keep track of your todo list.

This will not only help you with keeping track of what is critical, but it will help the users and your boss with seeing what your current workload is.

Also, should they ever hire a second developer (or you quit and your replacement now takes up your workload) this will help in managing the workload, and you'll be able to avoid stepping on each others toes.

Answer 21

The only way to break this chain is to develop new infrastructures that are designed for flexibility and are full unit+integration tested.

If you manage to sell this to the management (sign other developers and managers on to the concept in 1:1 meetings), then you can slowly reach a state, where most of the applications' code is in the infrastructure and it is easy to expand and maintain, whereas the actual applications are light weighted and can be written pretty quickly.

The development of the infrastructure may enable at first replacing parts of existing applications and after a while (may take a few years) replacing entire applications.

In the long run it can reduce development time of new applications and maintenance time of future existing applications drastically.

The new development will require at least 80% dedication (preferably more) with a team of more that one developer (a few minds are better than one). All the developers will need to be able to think creatively and to break existing preconceptions.

Try defining and high-level designing such a new infrastructure, then present the definition to your peers and to management.

As of your working conditions, ask to lead a new infrastructure team that deals with these issues (based on your definitions and design) and bring on new developers to maintain the old stuff while you assist them if necessary (up to 10-20% of the time). If the management agrees to the idea, you can ask to renegotiate your terms. Be prepare to find another job if they refuse. (Remember, your job requires skills, knowledge and experience, you are not as easy to replace as they are paying you to believe.)

Answer 22

Is your manager aware of all these change requests (maintenance requests)? Does s/he realise that your time is taken up sifting through such requests that you have no authority to sanction? Or do you just make changes everytime a manager asks you?

It seems to me like your first port of call is to put it all on your manager's desk. No one should be coming to you directly. Issues should come through whoever fields such - usually a support team. It is normal that you support your code for a short handover period - usually a week or so. Changes should be costed and charged (transfer charging) in any company that would class itself as "medium size", and this it seems is being bypassed (no wonder they are flooding you - you are like the slut at the prom).

There should be a proper request procedure for both raising issues and change requests. Support/maintenance is about fixing bugs and issues (that fit with the original specification, but fail because of a bug in the code or an outside event - such as a power down or corrupt upstream system, etc.).

If your company offers none of this and expects you to cope and be responsible for this myriad of random requests, then seriously you need to consider moving on. Pay is always poor at the bottom - in my first programming job (almost 25 years ago) I spent 8 years for the same company and my pay went up little (although it was always much higher than a cashier!). Within 2 years of leaving I had doubled it - and two years after that I was taking home over ten times what I started at (but was then an independant contractor). As always, earn you spurs, learn your trade, and jump ship to warmer surroundings.

Answer 23

Perhaps you're in a position to go to a manager and say: "Look, I'll be frank with you. My pay is terrible, I could get N times this as an entry level programmer at X.

I am doing way too much stuff with A, B and C. I can't maintain this. Honestly, and no offense intended, I'm going to walk out of this room with this either fixed, or with my resignation letter left with you. Now that this is all out in the air, how can we work together to make this right?"

Answer 24

The answer is to try and explain it in terms that can be understood;

• It's like oil changes. They aren't urgent.... but must be done regularly none the less
• paint over rust and it'll look great. Until it bleeds through
• build a new roof patio roof desk without strengthing supports. It will work for a while maybe. Then it will collapse and hurt people and you will be responsible.
• a/c is great. A window unit is great for one or two room. Trying to put 146 window unit air-conditioners in an aartment building and you will have... problems.
• Teaching 5 kids is fine. 10's not too bad. But there ARE limits. Try informally teaching 75 kids and you will see this.

If these are not resonating. Leave - THE DAY YOU GET AN OFFER ON WRITING, not the next day! Once you HAVE a new job, leave with ZERO notice. Literally just don't come in that day. But make sure you have a colleague or two who know what you did. This will actually help the company out, if the company can be helpd, by showing them that their disrespect and arrogance comes at a price. Last company I was at THREE OF THE FOUR TECH'S LEFT WITHIN 6 MONTHS WITH NO JOB TO GO TO. It made a statement at least and gave the leaving person once good chance to say, 'yeah, nice bs you say every day but you are so full of it, I'm not even giving you the satisfaction of my notice.

Finally, do know that this stae of affairs was the NORM and the standard 20 years ago before agile, tdd, bdd and refactoring became more then norm. You may be talking with senior people who immediately respond "well I have done this myself and it worked fine, blah, blah, blah." Well, s ure horses and carriages worked well 150 years ago. In technology areas, techniques from 20 years ago are as outdated as transportation from 150 years ago. If they reject this fine. Just know that they will never hire any decent current technology developers who will stick around. They will get the worst of the worst and it will hurt their business terribly. If they depend on technology and can't adapt they will fail and ultimately that may be the best reward for you. It's just that it may take a while as dysfuntional organizations can continue for a long time.

Answer 25

It sounds like your management fundamentally does not respect you or understand your work load.

You should not be implementing every feature request that comes through. Your manager should act as a buffer between you and incoming requests (except perhaps the most simple of break/fix requests). Then he or she should sit down with you and determine the feasibility and priority for any approved requests.

Also, you should be making probably 2x (at least) what they're paying you.

It sounds like they probably really need at least 1 more developer to work alongside you, but with what they're paying you that sounds pretty unlikely.

If they are unwilling to adequately pay you or help you manage your workload, I'd be looking for a new job. You want to work someplace where you're part of a team, and where your management works with you to complete your projects. Get off that sinking ship as soon as you can.

Being a hero on a team of one is only going to burn you out.

Answer 26

I'm only a student (still) but that's pretty normal (from my internship experience). That's what you get when working in support and web applications.

I'd advise you to understand what the client (manager) wants before starting coding. That could be tricky because sometimes they don't know it themselves so work with them till they agree on something. Make sure you both agree on the final solution before you code it.

Also if you are a maintainer you can pretty much change anything in the code - just make sure it doesn't change the behaviour or introduce bugs. I expect managers do not 'allow' you to change anything because they are used to and happy with how it is now and they don't want to pay for any new changes.

Finally, don't worry if you can't handle something because you're doing something else. I'd advise you to let people know that you are overwhelmed with work and their request will take time. If you don't managers would just think you're lazy. Do let them know you already have work and they might hire more people. There is no other way for them to know that the work is too much for a single person.

Answer 27

This is a project management problem. Use some kind of project management to decide what is of highest priority to work on.

a) You need a backlog of items to work on. You put your plan for improving the code in the backlog.

b) All the bugs go into the backlog

c) The backlog gets prioritized.

d) You do it all in priority order.

Bugs may very well be a higher priority, but if once you fix all that you have cycles to spend on new features or on refactoring design.

It's easiest if you just do refactoring improvements incrementally, as you pass over sections that have issues/bugs to fix. Then you can tell management, "I had to fix A, but B was fundamentally broken and I had to do solution C to fix it all so that D will be easier/cheaper in the future" Where A=The bug, B=The anti-pattern, C=Solution, D=Future Gains

If you can't justify work as an investment worth doing, business people will never accept it.

Answer 28

This is business as usual. You will be exploited as long as you keep working there it seems. It's in the company's best interest to continue going with this model rather than to make you feel happy in what you are doing. When it comes down to it, they don't really care. It's about creating reliable code for them and if you are a one-man-band, they are certainly making bank of you. Why would they change?

The good news in all this is you are a VIP to them even if they don't know it. What I suggest to do is to line up some more opportunities before jumping ship then grab them by the balls and demand a higher salary. If not move to a better opportunity. In my opinion, you should be finding some more exciting work soon. Aim as high as you can. Once you get to a developer shop, you will be much happier like Google or some fun startup where there is a collaborative developer culture where you will truly feel happy.

What I did personally was to use a head hunter contractor organization and quickly got many great experiences under my belt, moving from one to another while still maintaining a steady employment from my contractor. It keeps you from getting bored and challenges you. Eventually, in my spare time I built up some small business which blossomed into actual business, and then I jumped ship from doing contract work.