I started working in a company not much time ago, and what I see a lot inside a project is a high amount of low quality code and some custom ideas instead of industry standards and selected best practices.
But when I trying to talk with manager about that, I often see the answers, that guys who doing that make things quick and they are good etc, etc, etc
This is fundamentally a cultural issue. First of all, be careful of thinking you can "prove" that a different methodology is better. With time and experience, you'll get better about "persuading" your colleagues about better practices.
The problem is that the people in a shop develop certain habits, and come to certain shared understandings, and become quite comfortable in that. They experience "confirmation bias", in which their experiences confirm their bad practices ("I wrote that really quick and dirty, and we still shipped on time!") and discount evidence that contradicts their beliefs ("I spent three weeks on that bug, but I'm moving on to new code now.")
My experience is that the shops with bad practices are particularly resistant to good practices. The reason the shop settled on bad practices in the first place is that they weren't interested in alternatives.
On the other extreme, I've worked in shops that were so smart, and so open to new ideas, that it got kind of crazy because the infrastructure was so dynamic even from week to week, it was hard to tell how to write code and get it released (I'm currently in a situation where I've been waiting a month for a QA box, but they just re-engineered their code check-in workflow, so I'm back to square one, with no QA box. Or maybe square -1.)
As you stay with a shop, and as you gain responsibility, you'll have more and more influence on the culture. After all, the guy sitting at the keyboard ultimately makes a lot of the decisions. But it will be a long process of identifying specific things that could be improved, and either changing them individually yourself, or educating and persuading others to follow a better way.
...
...or, I should add, moving to a different shop. In this industry, sometimes the grass really is markedly greener on the other side.
In the case of refactoring, for example: Refactoring takes time. Time costs money. Therefore, refactoring is only worthwhile if you get benefits from it that outweigh the refactoring cost.
Just after you have created a kind-of-working solution, that's the time when refactoring is cheapest (because you know the code inside out at that point), and can give immediate benefits if refactoring makes bugs visible and debugging easier, so you get to bug-free code faster.
The other time when refactoring is useful is just before or while you have to make changes anyway, if the existing code is sufficiently bad, and it is cheaper to turn bad code into good code and modifying good code than trying to understand bad code and modify it.
Refactoring code that nobody looks at is pointless.
