There are several things you mentioned that I'd encourage you to continue to parse. Breakage, test coverage and code [quality] improvement are three areas you m

There are several things you mentioned that I'd encourage you to continue to parse. Breakage, test coverage and code [quality] improvement are three areas you mentioned. The assumption that refactor leads to breakage doesn't have to be true. It might be, if you are coding in a live environment, if you aren't feature / issue branching, if you aren't breaking up coding work into modular pieces, or any other number of scenarios. If that's the case, the benefits of a modern workflow should be discussed and a new process introduced. Baby steps. Thorough tests may be a side of a high quality code base. But, the value of them is about reducing bugs / errors. Start with that and lead by example. Once again, have a discussion about the value of adding something. Same with code quality...however you define it. Now, since you are new, it seems like you've worked other places that were engineering enlightened and you want to show everyone a better way. Be careful so that your enthusiasm / experience doesn't come across as you being an know-it-all, condescending, superior, etc. First, lead by example. Second, share, preferably when asked. Lastly, teach. If you weren't hired to modernize practices, and even if you were, you have to become a part of the team first, before you can change it. People have to know you're invested in them before they'll invest in you. Which is so say, no one cares about what you have to say, until they know that you care. Good luck!