14

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?

UPDATE:

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.

user36791
  • 157
  • 1
  • 4
  • 2
    Related: How do I explain ${something} to ${someone}? and, though from a different angle, How to explain business priorities to a programmer? – Stephan Kolassa Jun 04 '15 at 09: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 04 '15 at 09:34
  • Do you practice mandatory code reviews? I sometimes just say: This doesn't pass, please revise it, if the person doesn't agree I don't mind taking it with the technical authority (e.g. technical leader). And one more thing: What happens when you show this person he is incorrect? – Sigal Shaharabani Jun 04 '15 at 10:39
  • 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 04 '15 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 04 '15 at 14:32
  • 1
    Senior does not mean 'right' about everything. If they believe that, they are certainly not. – James Jun 04 '15 at 17:42
  • 1
    If you aren't the boss, then you don't. If you are the boss, then he changes or you fire him. Simple as that. – NotMe Jun 04 '15 at 18:20
  • 1
    Hi user36791, I made an edit to bring this a little more on topic here and hopefully the community will vote to reopen. – enderland Jun 05 '15 at 16:07
  • 1
    "stopped a long time ago...", "...never made an effort" - you have a remarkably detailed knowledge and understanding of this person, border-lining omniscience. I'm concerned you are over-estimating your understanding of this person and his motives/qualities. "how can I argue to get him to understand that he is wrong" - and I'm certain you are misunderstanding the goal of persuasion and argument. I'm reminded of How To Argue And Win Every Time - a good argument isn't making the other side lose. – BrianH Jun 05 '15 at 16:20
  • 1
    Never argue. Either assert if you're in a position of authority to do so, or discuss with the understanding that they may have valid objections that need to be addressed and hope that one side or the other is persuaded to change or compromise. Personally I recommend the latter whenever possible even if you do have the authority to dictate an answer, but either way presuming honesty and goodwill generally gets you to an answer faster and with less friction. – keshlam Jun 05 '15 at 16:58
  • You might consider the possibility that it is in fact those "pioneers of object-oriented design" who are wrong, or perhaps that both approaches have something to be said for them, depending on circumstances. But unless you can come up with a reason that's better than "because these authorities say so", the evidence says that he's a lot more likely to be right than you are. – jamesqf Jun 05 '15 at 19:57
  • You know, what you really need to do is get together with the author of this question http://workplace.stackexchange.com/questions/47548/how-to-explain-business-priorities-to-a-programmer and arrange to swap programmers. – jamesqf Jun 06 '15 at 00:28
  • I edited my post to fit the rules. – user36791 Jun 09 '15 at 00:25
  • I suggest the cluebat: http://ars.userfriendly.org/cartoons/?id=20030210 On a more serious note, the only working solution I've ever witnessed maneuvered the person in question in a position where their domain knowledge was used and their programming knowledge was not. – Peter Jul 08 '15 at 11:53
  • Don't argue, just quietly write your code the right way. He has infinite job security and zero reason to change; you will just antagonize him. From his point of view, churning out tons of non-reusable code minimizes the change of a bug (but also reuse), and maximizes his apparent productivity (in LOC, or bugs/LOC). Until the day management perceive that as being suboptimal and tell him to change, you have zero leverage. So just quietly do your own job the right way, until things change, if ever. Quite possibly they will never realize, or he will retire sooner. – smci Dec 30 '18 at 03:37
  • Also, influencing change is not a question of whether you are 'right' or 'wrong', but whether the people in power share your perception (or even know what's going on around them). We don't know because you didn't tell us their viewpoint, but based on your company not having any coding methodology, they either don't know or don't care. So don't try to change the guy. Work on cultivating your reputation, and don't make enemies e.g. if you ever see a bug-prone feature where a unit test would help, write it and prove the case for a little unit-testing that way. But don't try to evangelize. – smci Dec 30 '18 at 03:40

3 Answers3

13

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.

enderland
  • 110,742
  • 49
  • 328
  • 478
  • 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 04 '15 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 04 '15 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 04 '15 at 14:05
  • @Blam I didn't think so, but either way your comment was a good suggestion for my answer as the meaning of the first part of my answer definitely was not clear at all :) – enderland Jun 04 '15 at 14:06
  • 1
    @enderland Great post. If there's a stickying this should be stickied. – Florian Heigl Jun 05 '15 at 08: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. – YetAnotherRandomUser Oct 14 '18 at 18:19
7

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!"

oleksii
  • 544
  • 2
  • 8
1

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.