At our company there is some problematic developer. This guy works for more than 10 years for that company, so he has a profound domain knowledge and many people consider him competent. Because he knows that, he always thinks that he is right. But that's only half of the story.

This guy has stopped gaining programming skills a long time ago and he never made an effort to become better. I believe that good programming skills will not come from experience only, but from actively focusing on widening your knowledge.

This guy is resistant to good advice when it comes to writing maintainable code. Specifically he has the opinion that copying and pasting code is preferable over generalizing code, because then you can't accidentally introduce errors which affects unrelated code.

All pioneers of object-oriented design (like Martin Fowler, Kent Beck etc.), who have made great contributions to this community, tell us that we should focus on eliminating duplication and that following the DRY (Don't Repeat Yourself) principle is a good advice.

So my question is, how can I argue to get him to understand that he is wrong. How can I approach him to change his mind?


Thank you guys for all the great tips. Let me give an answer to your questions. First of all I went to that company nearly three years ago so I am not a senior in the sense that I am the one who dictates an answer.

I am just a guy with a high level of motivation who permanently improves himself. Secondly the person I am referring to is Deputy head of the department for development. This was not possible because he always delivered a high code quality but because he gained a profound knowledge of the business. Despite that, the company was very small for a long time and it lacked other capable team members.

I didn‘t mention that I am right just because Martin Fowler says so but because there is some evidence suggesting it. We are facing a growing number of problems concerning the overall quality. We need much time for modifying and maintaining the application and our team permanently introduces new bugs as well as regression bugs because of lack of encapsulation.

To complete the picture, we do not practice any code reviews, nor are we able to write unit tests for this application because it is a monolith. Our company has nearly no coding standards at all and there does not exist any real expert. As long as the complexity of the program was small, this code-and-fix paradigm seemed to be good enough (but „good enough“ is relative).

At the beginning of writing the application, our team consisted of three persons (the guy mentioned in this thread, a designer and me). Other coworkers do exist but they work on other projects. A half year ago a fourth man joined us. Fortunately he shares my view and he recently informed the department manager of the problems we are concerned with.

Therefore, I do not think that I am wrong. And everyone who says, that I am disrespectful and condescending, has a faulty perception of the situation. As you can see the stone only began to roll. Therefore, I am looking for advice because I think that I may profit from this situation. It is my aim to introduce coding standards and propagate a different programming paradigm so that our team becomes capable of delivering high-quality code.

  • 2
    Related: How do I explain ${something} to ${someone}? and, though from a different angle, How to explain business priorities to a programmer? Jun 4, 2015 at 9:12
  • 5
    If you are just a coworker does not sound like you are going to get very far. The bigger problem is lack of code practices at the company. Focus on writing good documented maintainable code yourself and rise to a level of more authority. Work within your sphere of influence not your sphere of concern.
    – paparazzo
    Jun 4, 2015 at 9:34
  • 4
    We're missing some important information here. Are you and this person on the same level, or is he senior? Also, what does your manager think about the situation?
    – Roger
    Jun 4, 2015 at 10:46
  • 5
    You are not necessarily "right". Just because you read in a book that its best practice does not mean it is always the best course of action. Without knowing the context, his approach may even benefit the business more
    – cowls
    Jun 4, 2015 at 14:32
  • 1
    Senior does not mean 'right' about everything. If they believe that, they are certainly not.
    – James
    Jun 4, 2015 at 17:42

3 Answers 3


Why is he thinking this?

Somewhere a senior person is (wrongfully) thinking, "man, there is a this guy who doesn't seem to care about how our business works and wants to change everything based on new theories. He is disrespectful and condescending and doesn't understand our business or care."

This is a misinterpretation of what is happening, but probably how he is thinking.

It's helpful when trying to change someone's perspective to understand where they are coming from and what they think about it (especially since in this case it's obvious you and the senior have very differently perspectives on this).

many people consider him competent

If he can continually deliver business value, then they are right. Period.

People are paid to generate value to their company. This comes generally in increasing sales or decreasing costs. Not writing pretty code. Not in being "best" but rather, being "good enough."

This is important. You cannot throw theories and terminology at someone who has, by the companies standards, been very successful and expect them to care.

Is he right?

Nearly all of the time you are right that better coding practices result in more value.

You need to focus your approaches on the business value that better practices create -- not the specifics. If he has been doing this for 10 years it's unlikely he will ever care about best practices if he has gotten "great" results with bad ones.

How to approach this

What you need to do:

  • Stop directly confronting them. You will lose every time, as you have found out, and make future battles harder.
  • Identify actual business problems you can resolve with better practices. Don't talk in hypothetical about things which are "good advice." Show it through your work.
  • Ask this person for advice periodically. No one likes a know-it-all, and if all you do is correct this person, you will come across this way. Ask about things, even if you feel incredible resistance. You will develop a relationship - which is nearly always critical to actually changing someone's perspective like this.
  • Ask them why they make decisions. Once you've done the above, start asking why - not "why don't you follow best practices" but if you can't understand his motivations and why he does what he does you will never change his perspectives.
  • Take time. You want to change someone's entire belief structure, which has worked for great success for them. If you insist on things changing NOW NOW NOW you will be sorely disappointed. Understand it will take considerable time before your "fixes' are accepted.
  • Code reviews. Have some sort of peer review process. This can be helpful, but if not done as part of the above will only make the problems worse.
  • Define expectations (only if you are manager). If you supervise this employee, you need to define clear expectations. Start small and slowly add them. If the employee doesn't follow them, you need a clear plan. Note this is difficult given their credibility internally.

If none of this works, you need to start escalating the business problems caused by this person, first to your team lead/manager. NOT the coding issues. The business problems.

If there are no business problems being caused by this person's work no one will care about your complaints. And you will find yourself marginalized by management.

Define your relationship with this person

You need to understand what your relationship here is. If you are team members, your approach must be different than if you are his team lead or manager.

If you are the manager, make sure that is clear to the employee and be prepared for office politics to happen if you reprimand a "good" employee - again, business reasons are important to others - not coding standards.

If you continue to be confrontational, especially if you are relatively new to the team, an older and more respected employee (by your company standards) will likely win ALL the office-political battles about this.

This is really important. You might get emotional "victory" against a "stubborn old guy" but they will probably win the war of getting other internal support.

  • 1
    You are reading lot more into that than I am. "Man, there is a this guy who doesn't seem to care about how our business works and wants to change everything based on new theories. He is disrespectful and condescending and doesn't understand our business or care." There in nothing in that to conclude OP does not care how the business works. Generalizing code is not a new theory - it is long time accepted best practice - he is right.
    – paparazzo
    Jun 4, 2015 at 13:54
  • 1
    @Blam I clarified what I meant by that. I don't mean that is the truth of the situation, but it is likely what that person is feeling and thinking - a misunderstanding, but probably still how they feel about the issue. It's helpful when trying to change someone's perspective to understand where they are coming from and what they think about it (especially since in this case the OP and the senior in question likely are at very differently perspectives).
    – enderland
    Jun 4, 2015 at 14:00
  • I did not down vote you. Calling him a perfect snowflake is not going to help him have better approach.
    – paparazzo
    Jun 4, 2015 at 14:05
  • 1
    @enderland Great post. If there's a stickying this should be stickied. Jun 5, 2015 at 8:19
  • 1
    +1 @ElysianFields "Man, there is a this guy who doesn't seem to care about how our business works and wants to change everything based on new theories. He is disrespectful and condescending and doesn't understand our business or care." This sounds like it comes from experience, and I'd like to see more of this sort of thing, whatever it might be called. Oct 14, 2018 at 18:19

how can I argue to get him to understand that he is wrong.

You don't, because people usually become rather defensive when challenged in such manner. IMO what you can try is to agree on common Definition of Done. If a task passes commonly pre-agreed objective criteria then and only then it is done. Otherwise it's not. Simply as that.

Definition of Done (DoD) can include things like:

  • Do we have a clear written requirement for a task?
  • Are there tests covering positive and negative situations?
  • Are common errors and corner-cases considered?
  • Is this code multithreaded, did we put guards for shared resource access?
  • Is this code duplicated elsewhere (you can start with "more than N times")?
  • Are there compiler warnings (you can start with "more than N")?
  • Has the code passed a peer-review process?

Once DoD is established it can be reviewed on weekly or bi-weekly schedule.

It may also help to have a 3-rd independent person, who can be a random developer from a team and who you grant ultimate decision power to consider arguments of both sides and to judge which argument is stronger. This can be helpful during a peer-review process and when no agreement can be reached.

I'd also like to emphasise to keep your conversation open and professional. You should only criticise task implementation or approach if you disagree with it, but not the person. E.g. prefer "This implementation is incorrect, because when A happens your machine will blue-screen, let me demo this..." to "You are a fool! This is not the way to implement this task, idiot!"

  • Definition of Done. That's an awesome term. Is that widely used, or did you coin it just now? Oct 14, 2018 at 18:20
  • @YetAnotherRandomUser it's more a less a widely used term, I definetely not invented this myself :)
    – oleksii
    Oct 15, 2018 at 10:30

As a team or someone in charge has to decide if anyone really owns the code. I think everyone should take responsibility for the work they do and take pride in how they do it, but that doesn't mean no one else is allowed to touch the code.

In some way, you both may be right. Copying and pasting code can introduce problems, but it can also be the quick solution when quick is preferable (not the most effective argument). Identifying code that has been copied and pasted without any modification from the original is difficult (code change could be made before being checked in.). Maybe this app has a history of things appearing to be the same but ending up changing anyway. I can't give an answer to all instances.

What you can do, is have code reviews and refactoring code. Although your process is not as formal, it seems like you've reviewed the code in some way and suggested changing it, but that hasn't worked. Having to alter something later is more time-consuming, but so is continuing to argue with someone you have no authority over. Maybe someone in charge will consider not allowing people to post code to production that the rest of the team doesn't approve.

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