Something I've always tried to drill into ambitious intermediate devs - you're writing the legacy shit of tomorrow, today! And when you're a senior, the next generation of ambitious intermediate devs will wonder aloud at wtf you were thinking when you wrote it, and it's just part of the software developer maturity cycle.
Code-bases grow through different phases along with the company - there's the "we need to ship the MVP, so just comment that out" codebase, then there's the "we're starting to understand the problem domain better" phase, followed by the "I just read a book by Martin Fowler/Uncle Bob, and I'm going to fix all the things", then the "wait, the problem domain is hairier than we thought, let's iterate on this", then perhaps, depending on company dynamics, the "a charismatic senior developer convinced enough people to use <technology X>, so we started moving towards it" followed somewhat later by "well, the senior dev left, and everyone decided that X was bollocks" moving away...
Or perhaps the entire model of the system changed. Your batch ETL pipeline delivered yesterday's data in time for start of today's business, and that was fine for a few years, but now the sales team want today's data refreshed twice a day, hang on actually, we want it updated every hour, now we want it updated within five minutes.
Code written for old paradigms always look crap when all you know is the new paradigm.