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