If you work at enough companies, even just one company, you'll likely run into some code you think is bad.
Sometimes the responsible developers have departed which is both a blessing and a curse: a blessing in the sense that the damage has abated; and a curse in the sense that they were probably the only ones who knew that code. Other times, the developers responsible are all higher than you on the company totem pole, which makes for a difficult uphill battle.
On top of everything, management is unsympathetic to your woes. Generally speaking, Management tends to be business-y types, not developers. Sometimes they're ex-developers whose heyday was thirty years ago when nobody talked about "Best Practices". Management doesn't care about code quality -- at least not directly. Management cares about hooking that big client, making that next sale, cutting costs, and getting that new feature out yesterday.
Are you doomed to toughing it out in a company you'll eventually hate because you soaked up all the bad habits and were beat over the head and lulled into bad-code complacency? Should you quit and try to find a new job?
No.
You don't have to settle and you don't have to polish off your resume. What if you could fix the system from the inside... make a real and lasting change for the better... earn the respect of your coworkers and boss... get a raise or promotion? Heck, even just experience greater job satisfaction?
These tips will help you solve your problems with your company's crappy code:
1. Be Positive and Tactful
How would you feel if you worked hard on something for a while and then somebody told you it sucks? Not great.
Besides, the more-senior devs are probably already aware that the codebase has problems. But often circumstances prevent them from being able to fix it (e.g. deadlines, management, the sheer magnitude of the problem).
2. Don't Perpetuate Bad Practices
Writing bad code and cutting corners will eventually come back to haunt you. Maybe not next week. Maybe not next month. If you're lucky, it'll be 4:59pm on a Friday; if you're unlucky, it'll be a 3am wake-up call.
If you already have good coding practices, follow those. Otherwise read everything you can about best practices for your language and environment.
3. Learn the Code
Is the code actually bad or have you just not taken the time to read and understand it?
Adding code comments as you figure out what each section of code does is a great way to help both yourself and those who follow.
4. Fix as You go
Refactor and clean up code in areas where you are already working on assigned tasks. Avoid making changes in unrelated code.
Also be sure to add unit tests!
5. Lead by Example
Build credibility with your coworkers by writing clean, concise, and well-documented code.
Be able to show how your code is easier to maintain and use that as fuel for driving change.
6. Code Reviews
Ask your manager about getting the team to do code reviews. You could also ask your coworkers directly to review your code. Maybe they will learn from you. Watch for checkins and review their code -- but remember to approach a coworker politely and positively ("Should this variable have been initialized?" vs "How did you miss that?").
7. Go Over Their Heads
Sometimes people are just really stubborn and don't want to change. If you've taken your concerns to a developer and they just brushed you off, it is appropriate to escalate your concerns to your manager. Sometimes there's a bad apple that has to go. But what if your manager also brushes you off? Keep escalating or drop it.
You're not likely to win any friends with this strategy. Best case scenario is the one developer is the sole source of the problem and you get him fired.
8. Make a business case
Management can be more receptive if you can tie poor code quality to wasted money. E.g. takes longer to fix bugs and add features, more time spent bouncing between devs and QA, lower customer satisfaction due to high bug count, more customer support resources needed, etc.
9. Polish off your resume
If nobody is on the same page as you and your coworkers and management are pushing back against you then you need to seriously ask yourself if you belong with that company.
Maintaining legacy code is almost a given in our industry. If code quality matters to you (and it should) you owe it to yourself and your company to ensure you've got a solid code base. You can never be happy at a job if you hate the code.