I'm in a very similar situation to yours: A startup using java, quite profitable, outside funding, bad code, stubborn CTO, database used as dumping ground for everything: logs/stats/messages etc (this is very wrong when you're working at the kind of scale that we're at).

(Hey...! Are you the new guy that sits by the water cooler?! I hope thats not my code you were talking about!)

Here's what I did:

- I ended up getting into a small argument with the CTO. He now knows that I'm smart enough and treats me with respect. I stood my ground but also offered solutions to improve and also accepted some of theirs.

- After working for a few months, I've realized that even though there are bad parts, some parts are actually good. New/other devs are improving the codebase.

- I file bugs with regularity- I didn't do this at the start but just picked it up. This way things that I come across go into a bug tracking system and can be handled eventually.

- Now that I'm involved in more parts of the code, I can refactor small bits as I come across them with my daily tasks/projects.

- There are other things that I'm collecting in a document which I'll converse with the PM etc about. Most importantly all these will be things that I can do and will not blame the CTO. For e.g. setting up a wiki, documenting the setup process for a new dev (win/unix both), common errors, people on the team, machine ips, purpose for each machine etc.

You have to realize that the world isn't ideal. Because of whatever reasons (bad coders, managers, deadlines etc) projects end up in a crappy state all the time. Make small changes to help and improve that, and you'll be worth 100x more to the company rather than if you just whine about it and blame someone else.

Note that this isn't about accepting crap policies just so you can have an income- this is about realizing that a lot of this stuff is common and being able to improve it. Also realize that you dont know everything in your first week. Your views will certainly change in the coming months.

Finally, the company is profitable. A lot of companies get that way by making compromises in the short term (one of those might be bad code quality). This is a situation that can be improved upon. Bad code and a profitable company is a better combination than elegant code and a bankrupt company.