In a nutshell
There is a new developer to a company, bringing new ideas to a project. While said developer solely owns and works on the project, the changes being made have caused distress to other developers in the company. What is the best way for the new developer to handle this?
There are multiple projects in the company, but "Project A" is generating a good part of the company income. It is built with a old technology stack and the workload is enough for one programmer.
There are two programmers now at the company who once worked full-time on Project A - let's call them "Programmer A" and "Programmer B". They now work elsewhere in the company.
The new programmer in the question is the third programmer to be hired to work on Project A. The previous two programmers were both hired separately, working in succession of each other for only a few months on Project A before leaving.
Our new programmer has invested some personal time in the evening and week-end to improve the code so it will be more enjoyable later to work on this codebase. He has also refactored the code to decoupling it just enough to start developing tests because there is no QA in the company.
Both Programmer A and programmer B seem to be irritated about the culture of change this new programmer is bringing to the project. One of them asked him to focus more in delivering than refactoring.
How can the new programmer positively boost his brand while simultaneously increasing the quality of the project A code base? The new developer does not wish to abandon his principles of software craftsmanship.