Dealing with messy code
I've been on both sides of this issue in the span of my career. I've joined companies with absolutely horrific code, and I've hired people who thought my code was shit.
My advice is don't complain and don't attempt any significant rewrites for the first 6 months or so. Your job at first is simply to understand the code and demonstrate that you are able make improvements to it without breaking everything. Doing so will win you the trust and respect of your teammates, whereas if you come right out of the gate trying to rewrite everything there is a very good chance you will make yourself look like an ass by spending a lot of time and energy introducing bugs into a previously-stable area of the code. Once you have a decent understanding of how and why the code is the way it is, and the trust of your teammates, then you can invest effort into fixing the highest-priority issues with the code.
Being able to read and work effectively in legacy code is an essential skill for any software engineer. For now you should just try to focus on fixing bugs and implementing new features, and take pleasure in the fact that you are improving the project and developing a handful of hard and soft professional skills.
That being said - there should be a limit to how much bullshit you put up with. If after six months to a year you still find that you hate the job, and a better opportunity comes along, then go ahead and take it.
From Ask HN: Codebase at my work is a complete mess, what should I do? - Published 2018-08-23 on Hackernews