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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.