The existing devs will hate you. They already knew how it worked - now they may not even you've finished - and unlike normal refactoring you never knew how it was supposed to work.

This is a good way to cut the velocity of whole project so you don't look as lost though.

I don't think the point is to move the refactor into production. The refactor is a learning exercise. But if you start on the least understood, ugliest parts of the code the devs might welcome a refactor of those bits.

I sometimes do this with code that nobody understands but generally you should first talk to the people already there and understand the code.

Note, I did not say "commit to Production". Just set up the feature branch and tear it apart. Most code out there has 0 comments and uses conventions from when it was written (god help you if it's a legacy product)

In that case this is a good idea... I apologize for my skeptism. I've experienced the someone doing this and then committing to production though - I left that team as soon as possible...

Yeah, that is super sketchy.

Nah, I usually just do a feature branch, refactor items with better stuff and we can then cherry-pick anything that's sexy and still fits our business needs once we've talked it over.