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?

More details

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.

  • 5
    Is there a way you'd be able to trim your question down a little to concentrate more on the conflicts between Programmers A, B and 'New'? – user34587 Mar 20 '18 at 16:32
  • What exactly is the problem? Him refactoring or programmer A&B having to work on it? – Dan Mar 20 '18 at 17:11
  • 1
    If Programmers A and B have moved on to other things, why do they care what New Guy is doing to a project that they no longer work on? What kind of company would assign a new hire to be the sole owner and developer on a project that brings in a good part of the company income? Can you really even have a "culture of change" when there's only one person working on the project? – Caleb Mar 21 '18 at 4:04
  • 1
    @bharal Thank you for your edit, the question is more concise and craftsmanship was the perfect word. – not initialized Mar 21 '18 at 11:44
  • 1
    “The New Programmer” is you, amirite? Isn’t there a boss in this equation to tell y’all what to do? – Ernest Friedman-Hill Mar 21 '18 at 12:19

How do the changes to the code align with the company's strategy for Project A? How do they align with the company's strategy for software development processes?

Sometimes a "good" idea isn't the "right" idea. Good ideas are only good in the right context. The New Programmer needs to make sure he is working within the boundaries of what is expected of him. If he has ideas for changes, he should make sure he is discussing them and promoting them through the right channels (leadership in the company) before implementing them.

If the new programmer is aligning with the company strategy and practices, the relationship between him and A & B gets a lot easier, since he has that strategy as his backing. If the new programmer is simply trying to do things better all on his own, then frankly he should expect a long and messy battle, because he doesn't have much ground to stand on.

To directly answer your question,

How can the new programmer increase positively his image while achieving the goal of increasing the quality of the codebase on project A that nobody except him is working on it?

It sounds like A & B are taking the New developer's changes personally, as if the New developer is insinuating that their work was no good. It's easy to be upset when a new person comes along and points out problems with things you've been doing (apparently with success) for years. If that new person isn't even aligned with company policy or strategy, it's even easier to take their criticism personally.

If the new programmer is working in a way that doesn't align with expectations or culture, there may not be much that he can do. If that's the case, the best way to make his image more positive would probably be to fall in line with those expectations, even if they don't match his personal idea of what is "right" or "best" for the code. Or, focus on the specific changes that have practical, obvious implications. Make it about the quality of the project, not about pointing out the mistakes in the existing code. Look towards the future, not the past.

If, however, the company **does* have an expectation of developers making the kinds of changes the New programmer is making, he can help A & B understand how his changes align with those expectations. Again, present it in a way that isn't personal, where possible.

  • Interesting answer, but you don't answer the q: "How can the new programmer increase positively is image while achieving the goal of increasing the quality of the codebase on project A that nobody except him is working on" – bharal Mar 20 '18 at 17:27
  • I edited my answer to directly address that specific question. – dwizum Mar 20 '18 at 17:45
  • i'm not sure you directly address it - you basically tell OP "there is not much that can be done". You have an interesting idea with "focus on specific changes", but don't develop it. Again, with your last paragraph - interesting idea, but undeveloped. – bharal Mar 20 '18 at 18:44
  • “he can help A & B understand how his changes align with those expectations.“ - It isn’t the job of this developer to sell their ideas and changes to their project to non-teammates only to their manager. The people complaining are out of line. – Donald Mar 20 '18 at 22:52
  • @Ramhound yes, I think we're indirectly saying the same thing. It's up to management to set a strategy and approach and developers to follow it. Ultimately though I think there's a reasonable expectation that staff will sometimes provide each other feedback and criticism. And it shows good initiative that "New" wants to address that criticism, although they first need to understand if they're "in line" with overall strategy and address that if they're not - since it doesn't seem clear that "New" is actually doing what management wants them to or not. – dwizum Mar 21 '18 at 15:02

The fact this is the third programmer in recent history you've tried to hire makes me think more of the problem lies with you, and not the person you hired. I personally don't see any problem with what the new developer is doing, so long as it's not interfering with deadlines. You can always make changes tomorrow to make your job easier, but it's what is due today that matters.

Since he's new to this code, he wants to protect his butt with improvements and tests by not delivering changes that break something important. I wouldn't call that being a "Smart ass", that's just being smart. If a building contractor took over a project and noticed the foundation weak and the building was eventually going to crumble, would you expect him to fix it, or just finish the building to spec.

You hired this guy to take over this project, right? So let him take it over! Both you and your buddy (Programmers A and B) no longer wanted to work on this project, you got what you wanted, a third developer. Let him make it his masterpiece, and you'll likely have a long term employee. Nit pick every little thing he does, and look forward to taking back this project in the near future when he quits, like the two former employees did.

If I were speaking to the new developer, I would stress he needs to "sell" his ideas, not force his ideas upon his new management. Get everyone in the same room, state the problem, state the likely outcome if said problem isn't corrected. State your proposed solution, and your timeline for getting it implemented without affecting company deadlines.

Just some advice from a seasoned developer...

  • 4
    um, OP is probably the "new" programmer, you've misread the q – bharal Mar 20 '18 at 17:25
  • 1
    @bharal, since all the references to the programmers were written in the third-person, I figured this post was written by their manager. – Jay Mar 20 '18 at 17:36
  • 1
    Unfortunately the question is very vague. What exactly is the OP trying to resolve? Getting Programmers A&B in line? Is the new programmer missing deliverables due to refactoring? And as demonstrated with this question, who is the OP relative to these people? Hard to say. – Dan Mar 20 '18 at 17:58
  • I'm going to redirect the YOU to Developers A and B. To call somebody a smart ass in the workplace is highly unprofessional, and... as anybody can imagine, programmers are supposed to be smart. The direction here might be to hire two more of programmer C and adjust the head account appropriately ;) – RandomUs1r Mar 20 '18 at 18:12
  • @raterus no, you've misread the question. also, failed to answer the question - "what does new do", instead decided to discuss what A &B should do. – bharal Mar 20 '18 at 18:40

If you give someone autonomy and they're delivering satisfactorily then protect their autonomy.

The new guy owns the project, the other 2 have moved on, they should not have a say.


The new developer does not wish to abandon his principles of software craftsmanship.

Was the new one employed to change everything, to give structure to the project, to lead the project and take response for delays and everything else? Then forget my text. If he was employed to help deliver, go on reading and prepare for trouble.

Would someone get the job if he'd say in the interview "I make clear that I have my way to work and YOU should adapt to me, I won't adapt to you"?
New ideas are great if they are helpful. But not everything new is really helpful. Colleagues don't wish to change everything to the latest employed programmer's ideas.

Programmers learn new things every day. This subject is changing quickly. So it's quite normal to have different ideas or views between programmers. Now it's up to you all to bring all these ideas to one common level. This level always changes but slowly step by step, with discussions instead of "hey I know better than the rest". If this person is the new member, things are even harder and colleagues will be even more negative.

You should ask this at stackoverflow, a programmer's forum. If you want to share more details about who does what which way, there is a chance to get more detailed opinions on your special situation.


Programmers A and B should not interfere with decisions related to code that someone else has to maintain

While new programmer delivers there is no point on interfering in his or her practices


Who is in charge? How this affects the business should be considered.

One of them asked him to focus more in delivering than refactoring.

Can the company afford to take this long-term approach? Getting rid of technical debt is great, but not if it means bankruptcy. Everyone wants quality code. You have to make sure there is someone who is going to pay for it.

The other developers have given their input. Now it is time for someone to make a decision. If the group has the authority, take a vote. These decisions should have been made before a new hire was put on a project by himself. If he falls behind, the other developers will have to pick up the slack.

Not the answer you're looking for? Browse other questions tagged .