[j_z_reeves]

I welcome a coworker refactoring a section of the codebase to make it easier to change in the future. I do not like it when a coworker, new to the project, assumes that a certain way is incorrect. Like, introducing docker and additional tooling when no one asked for it. I especially do not like it when abstractions are unnecessarily forced.

Another perspective, if I am busy building out a feature and I open my source control to several huge PRs containing trivial changes, I groan. Now, not only do I have to respond to these PRs in a timely manner, I have to ensure that the changes are part of a codebase's design roadmap.

Large refactorings should be discussed, agreed upon and expected. Breaking a several thousand line module into a folder containing separate modules is nice and a welcome endeavor. I just don't want to see it as part of a feature PR. Discuss it and create a separate PR.

Also, just because you refactor, doesn't even your refactor is good. You can refactor in a worse off way as well. Your refactor may make the codebase nicer now, but could prevent easy changes later. Your refactor may go against best practices. I have seen this from developers that are on the Dunning–Kruger spectrum. Once again, refactors should be discussed and agreed upon.

As a side note, this seems like a great interview question to determine cultural fit. I do not want to work with a "fred" that doesn't communicate concerns and intentions.