Imagine you've just been hired to fix a horrible legacy system.
You've just been handed a giant monolith that talks to customers on the internet, accesses 4 different internal databases, handles employee and customer on-boarding, sends marketing emails, contains a proprietary task scheduling system, and has concurrency issues. Which problem do you tackle first?
Separation of concerns? Maybe the massive number of exceptions in the logs? Probably none of these.
The first thing you really need to learn is why you been hired to fix the system in the first place. Ignore the technical problems, what are the business problems with the current system? What does the business need done so badly that they've hired you? Your fellow programmers care about how difficult the current system is, but the business cares about how hard it is to get what they need. Don't confuse tech problems with business problems.
Learn the business problem that justifies your salary. Find a way to provide that value. You can fix or replace the legacy system over time.