Probably you are familiar with the theory of broken window, if not I will give a quick definition of it here:
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside
Paraphrasing it, our perception of the whole system greatly depends on the number of small quirks and misfunctions of it. The more quirks ("broken windows") it has the more likely it will become no-go area for us.
The same theory we can apply to the codebase. I believe you've seen in the projects you've been involved in some files or modules which was really uncomfortable to work with: thousands of lines of code, no comments, huge methods, overcomplicated logic and etc.. Most probably it was not written in such manner initially, but become after years of modification. What happens it that whenever you(or someone) have to work with such code, unintentionally you think that since that code is already "bad" one more "broken window" will not make it worse. To improve it we will need to change our perception of "bad" code.
On a daily basis if you see that code looks weird, cryptic or it is simply hard to work with it - try to improve it ("fix the window") in the simplest way. If you have just a little time - improve the variable naming, if you have much more time - try to refactor it or add missing unit tests to make subsequent changes safer.
Next time you see a broken window, don't just pass by but try to fix it.