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