It seems like you are asking two different questions:
How do you approach work involving legacy projects?
How do you deal with having to work with legacy projects?
Let me know if I have misunderstood, but I will answer the two questions that I read from your post.
1. How do you approach work involving legacy projects?
You wrote:
maintain their monster-size code-bases often written in outdated frameworks to fix bugs while avoiding damage to major dependencies.
So it sounds like you're working with poorly documented, not tested, possibly in-house made frameworks that have bugs or need additional features built. And you are thrown at the task, and expected to do the work.
I would start with a few questions:
What is our timeline for the work?
Given that timeline, how much time can we spend investigating / documenting / adding tests to understand the legacy code?
If the required work is more than a small bug, and the timeline is unreasonable, I definitely express that thought and push back for a more reasonable timeline, especially if it's my first time with the legacy codebase. If the timeline is immovable, and the work is fixed in scope, then I make sure to mention that this should be an exception, and that I will actively avoid or refuse that sort of work next time. (We are fortunate to be in a career that is in high demand right now, so I think we have leverage.)
Now that we know the timeline and work required, I would go through the concurrent acts of a) finding where the work needs to be done, and b) documenting and adding tests for as many places as I can on the path to the work to be done.
This allows me to solve the problem at hand, but also make the codebase easier to pick up next time someone else (or myself again) needs to do work. Even if it's as simple as "running this locally" instructions, it's better than nothing!
2. How do you deal with having to work with legacy projects?
You wrote:
How do you keep motivating yourself to deal with continuous legacy projects? Or do you try to avoid them at all costs?
The real meat and potatoes of your post, in my view, is how does one continue to develop their career positively while having to work with legacy projects. It's a great question everyone should ask themselves, if they are ever posed with the situation.
Having been there personally, there's a few thoughts I had while my team took on more and more legacy services, and having to maintain them while building out new features:
Opportunities to improve documentation and testing, which are important skills to build and develop as software engineers, but are also helpful for developer ergonomics should another team also want to build out features in the same legacy code
Opportunities for refactoring code and optimizing performance / readability in an older / legacy codebase, which is done in a much more controlled way with proper documentation and tests, and can end up saving the company time and money (through faster development, or through fewer resources uses)
Opportunities for project management and communication; if you are maintaining or building out legacy projects, you can get some real practice in understanding the business problems at hand, and how you can scope + plan + communicate the technical solutions you intend to build out
In the event that the above opportunities do not exist for the work you are doing on the legacy codebase, then I would communicate that your career growth is being negatively affected by the work, and ask for either additional work, or to be moved somewhere else entirely.
If that's not possible, it could be time to start looking for new opportunities.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It seems like you are asking two different questions:
Let me know if I have misunderstood, but I will answer the two questions that I read from your post.
1. How do you approach work involving legacy projects?
You wrote:
So it sounds like you're working with poorly documented, not tested, possibly in-house made frameworks that have bugs or need additional features built. And you are thrown at the task, and expected to do the work.
I would start with a few questions:
If the required work is more than a small bug, and the timeline is unreasonable, I definitely express that thought and push back for a more reasonable timeline, especially if it's my first time with the legacy codebase. If the timeline is immovable, and the work is fixed in scope, then I make sure to mention that this should be an exception, and that I will actively avoid or refuse that sort of work next time. (We are fortunate to be in a career that is in high demand right now, so I think we have leverage.)
Now that we know the timeline and work required, I would go through the concurrent acts of a) finding where the work needs to be done, and b) documenting and adding tests for as many places as I can on the path to the work to be done.
This allows me to solve the problem at hand, but also make the codebase easier to pick up next time someone else (or myself again) needs to do work. Even if it's as simple as "running this locally" instructions, it's better than nothing!
2. How do you deal with having to work with legacy projects?
You wrote:
The real meat and potatoes of your post, in my view, is how does one continue to develop their career positively while having to work with legacy projects. It's a great question everyone should ask themselves, if they are ever posed with the situation.
Having been there personally, there's a few thoughts I had while my team took on more and more legacy services, and having to maintain them while building out new features:
In the event that the above opportunities do not exist for the work you are doing on the legacy codebase, then I would communicate that your career growth is being negatively affected by the work, and ask for either additional work, or to be moved somewhere else entirely.
If that's not possible, it could be time to start looking for new opportunities.