On one of my first projects, I was so afraid of "spaghetti code". Before adding any substantial feature I searched for "best practices" and tried to implement them, made sure my file names and folder structures were organized, wrote unit tests, then wrote integration tests, then manually tested -- all before I had a single customer or another developer on my "team". Looking back, I was very slow. I think it still would've failed if I was a bit faster, but who knows.
Then at my next job I had almost the exact same experience as you. 400-600 line methods, no logging, reliance on outdated libraries/frameworks, no documentation. Fixing bugs meant trying to change as little code as possible, because if you actually tried to refactor you would almost definitely end up altering or breaking some other feature. Yet there were large companies that paid for and relied on the software for business critical processes.
I'm still trying to figure out what the balance is, but I'm glad to have experienced both ends of the spectrum.