Legacy maintenance builds the developer's desire for good practice
I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.
I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.
It has been my predominant experience that developers who write bad code are in one of two camps:
- Those who didn't know any better
- Those who think they are doing the right thing
The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.
Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.
The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.
This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.
What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.
As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.
Cleaning up after others
You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.
Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.
I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.
On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).
Addressing the issue
Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.
In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.
But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.
The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).