8

I have an employee working for me who writes code in an overly complex manner occasionally. His code is not bad, and it generally follows all best practices, so our disagreement is only on style.

However, I have asked him to change his code to suit my requirements, and he has not been willing. At one point he told me I should make the changes myself, and I did it that once. But it has come up a second time, however, he refused to do the required changes, so I did them myself again. However, I do not want to do this again.

I have already tried explaining to him the reasons I want changes made (and he definitely knows how to do them as my way is far simpler), but he never agrees - largely because the disagreements are down to coding style. (And because I am not good at swaying people in any situation.)

How should I communicate to him that he must code as I request?

Simeon
  • 83
  • 1
  • 1
  • 3
  • 2
    Are you his employer or his manager? – Dustybin80 Jul 10 '15 at 14:46
  • @dustybin80 - Both - I am the owner of the company. It's a small company with only a few employees. – Simeon Jul 10 '15 at 14:55
  • 2
    @gnat Not a duplicate of that one, but a duplicate of the one that one was a duplicate for. :) Thanks for pointing me in the right direction. Apologize for the duplicate. – Simeon Jul 10 '15 at 15:08
  • you mean, How do I deal with talented, but difficult employees? That's my fault sorry. I was choosing between these two and picked one where question felt like closer to your. But now that you mentioned it, I additionally checked answers, and I think you're right about it being better duplicate :) – gnat Jul 10 '15 at 15:30
  • Choose your battles wisely. If he is following best practices and his code works, not sure I'd go to battle over style, especially on a very small team/company. – cdkMoose Jul 10 '15 at 16:09
  • 3
    ...by the way, no need to apologize. :) Duplicate questions are officially considered okay. See Dr. Strangedupe: Or, How I Learned to Stop Worrying And Love Duplication at Stack Exchange blog – gnat Jul 10 '15 at 16:15
  • For this specific case, I recommend making him get his code reviewed before it is checked in. It doesn't get checked in until it is done to your standards. You can remove the restriction once he has learned how to do it right. – DJClayworth Jul 10 '15 at 16:17
  • Have you asked why he doesn't code in the style you want? Maybe he has a good reason. Personal example: I am the only person with previous experience in Python in my office; my Python code looks a lot different than everyone else's, but that's because I follow PEP 8 guidelines, which my co-workers haven't heard of. Alternatively, maybe this guy is just having a difficult time changing long-established habits. Also, you might try pair programming. – GreenMatt Jul 10 '15 at 16:49
  • Make use of static analyzers that check for style issues and then tell the employee that the task is not complete until all reported style issues have been resolved. – Brandin Jul 11 '15 at 08:28
  • 1
    Replace this employee with someone better already. – Bradley Thomas Mar 15 '16 at 15:40

2 Answers2

11

You take this employee into your office and have them sit down.

Then you explain that their work is not to the standards you expect. Be detailed on what you are looking for. Tell them you will be reviewing this again in 30 days and that if there is no improvement that they may be fired.

One of two things will happen. Either the employee improves or you find someone that will perform the work you want.

You might want to review the following: http://www.shrm.org/templatestools/howtoguides/pages/performanceimprovementplan.aspx

edit
As the owner of a small company there are numerous decisions you will be faced with every single day. The first question you need to ask yourself for each of these is: Is this decision critical to the success of my company?

If the answer is No, then delegate it away and don't worry about it.

However, the difference between writing complicated code and simple code can be a death bell for a small tech company. If your code is too complicated then it will be harder to maintain. If it's too simple then you might be throwing it out and replacing it far sooner than you hoped. There's also your exit strategy to consider. If you start looking for someone to buy your company, which path do you think they will prefer?

There's no right answer HOWEVER the question boils down to one of risk.

One such risk is that this person continues producing complicated code then leaves. The amount of time it would take a new developer, or yourself, to get up to speed could mean the difference between staying in business and closing the doors.

IMHO, at this stage you need to have an absolute iron fist on how you want things done. It's your company, remember that. At the end of the day these people depend on you to make sure they get a paycheck and they depend on you for direction. If you don't provide direction, they'll leave. If you're wishy washy then your company will fail.

I understand HLGEM's statement about "If you believe the person should have the freedom to determine how to do the work as long as the end result meets the standards, then you need to apologize to him for trying to interfere." and in a large company I would agree with that.

However in a small company like yours there is often very little room for failure and letting someone rebel against what you are trying to build simply will not work long term.

NotMe
  • 23,390
  • 5
  • 70
  • 104
  • 2
    Thank you @NotMe. That is very good advice. Although it's a small thing that is not critical to the business - my biggest concern is that I need to be able to maintain his code if/when he leaves. Although I can follow it, I want to make sure he is writing code that I (and everyone else in the company) can maintain - it doesn't matter how clever the code is if no one else can understand. This has given me the talking points I need for my conversation. – Simeon Jul 10 '15 at 15:45
  • Code that few can easily understand is Bad, no matter how perfectly it performs the initial functional spec, because maintainability is an essential requirement to keep down your Total Cost of Ownership in an IT system. – Bradley Thomas Mar 15 '16 at 15:39
8

Your disagreement is not on style at all. Your disagreement is on how much a manager should control the output of the person doing the work. He is being insubordinate. You have set a standard that he disagrees with and refuses to follow.

You need to evaluate if this standard is important enough to lose this employee over because he clearly feels that it is his right to set his coding standards not yours as his boss.

If it is important enough, then you sit him down in a private place. Tell him his performance does not meet your standards and that if he doesn't start to meet them, he will be fired.

If you believe the person should have the freedom to determine how to do the work as long as the end result meets the standards, then you need to apologize to him for trying to interfere.

HLGEM
  • 142,324
  • 26
  • 258
  • 516
  • 1
    Question: Has he (the owner), in fact, set the standard? Are there style guidelines in place? Is there an enforcement/audit tool (ala Resharper)? Or is the owner being subjective? If there are objective coding standards in place, then I'll +100 this answer. – Wesley Long Mar 15 '16 at 16:49
  • If an employer told me "performance does not meet standards" and "you will be fired," I would start looking for a new job immediately. Same day. Even if we patched things up later, I would never, ever feel the same loyalty to the employer, and would probably leave soon anyway. Coding standards are important, and the coder probably needs to be persuaded. But that level of aggressive bluntness will poison the relationship permanently. Good coders are in high demand. I would leave. – MealyPotatoes Mar 15 '16 at 16:53
  • 2
    @MealyPotatoes, and I would be happy to see you go. If you can't or in this case won't meet the standards, you should be gone. – HLGEM Mar 15 '16 at 16:59
  • HLGEM: Yes, I agree -- if your starting position is, "do it my way, or your fired," then we would not be a compatible team, and it would be better for both of us if I left. However, I would recommend trying a little persuasion before threatening termination. First bring the topic up in performance review. If problem persists, inform him in writing that he must follow (written) coding standards, or he will be put on probation. If that doesn't work, then you start using words like "although we appreciate your contributions, we will have to part ways," etc. – MealyPotatoes Mar 15 '16 at 17:30