Been there. One of my more-recent companies was like this. So few tests, 200+ line methods, no style guides, etc. The problem isn't going to be the code - you

Been there. One of my more-recent companies was like this. So few tests, 200+ line methods, no style guides, etc. The problem isn't going to be the code - you can fix that. It's if management is actually ok with things changing. So often there's resistance to change for a variety of reasons, some good - some bad. Bad ones include "it's too hard" or "Well, this guy wrote it this way and we don't want to hurt his feelings". At least they are into bug fixing. I've been at companies that were feature-focused 99% of the time, because the CEO and VP of Product had overpromised so much to clients and investors that we were always chasing some overly ambitious fairy tale. Quantity ruled over quality. When things broke or didn't scale, they acted like they had no idea why. It was always more more more. These situations are the ones that can't be fixed. Run as fast as you can. But, if they are amenable to getting a plan in place and working on this stuff slowly, then it surely can be fixed. Bug fixing is important though, as I don't want to try to refactor broken code, only to break it more.