About 2 years ago, I was in the same position as you. Had been freelancing for years, then went back to full-time employment. It was quite a change from what I

About 2 years ago, I was in the same position as you. Had been freelancing for years, then went back to full-time employment. It was quite a change from what I was used to. IE: working with a very small team of people I chose and have worked with before. A lot of the advice I've seen here relies on the rest of the team wanting things to get better. That's not always the case. Many teams are very proud of their unmaintanable, untestable spaghetti. Some see it as a of badge of honour that nobody else can figure out something as basic as where model validation happens (in that specific case, they marshalled all their model validation into the controller parent class, and things got worse from there). So the first thing you need to do is figure out how open they are to changing. If they're happy with what they've got, and they don't want to change how they write code, then there's not much you can do. Cleaning as you go is a great idea. But even if there's only one other person on the team and and they don't want to change anything, they'll be generating mess twice as fast as you can clean (making a mess is always faster than cleaning). That's my advice. Try to probe if they're willing to admit they even have a problem. Start with floating the idea of writing tests, or implementing a style guide. If they don't even want to do that, there's no way you're gonna get anything bigger out of them. At that point, you gotta decide if this job is right for you.