Nobody likes to maintain a bad codebase. And still, it's an experience that i'd recommend to every developer, particularly early on in your career. People who are relatively new to coding usually don't have a good view yet on what kind of code will cause pain in the long run, and what kind of code won't. And if you keep getting assigned to new projects, you're less likely to develop that view properly compared to someone who has to maintain an existing, problematic codebase.
We've all heard the most common ways of improving as a developer: read the right books, learn from more experienced people, and above all: practice, practice, practice! And all of that is indeed very important. But i've always felt that being exposed to bad code and having to deal with it can be a tremendously important and valuable learning experience as well. As valuable as repeated practice, reading and following advice from experienced and skilled developers is, none of it will stick with you as long as the pain you feel day in, day out from working with a bad codebase.
When you're working with a bad codebase, it's important to figure out where the pain comes from. Whenever you experience pain while trying to make a change, or while trying to implement a new feature, take a bit of extra time to look for the cause of the pain. Then try to think of a way that would avoid the pain entirely, or at least lessen it. And if you can, implement your solution in the codebase. If you can't, try the approach you thought of in a personal project. If you do this routinely, you're going to learn a lot about what works well and what doesn't. I'd dare say that you'll get a better view on this than people who never have to work with legacy code, since they rarely get exposed to the long term problems caused by the code they write.