Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How do you deal with a senior developer who does not think that the company standard way of developing software applies to them ?

For instance:

  1. Will ask other developers to do work by email, rather than assign bugs to them.
  2. Will keep copies of documentation and code in their own local area, rather than keeping them in the common area under source control. (and overwrite others changes with theirs)

NOTE: This has been flagged to QA people before.

share|improve this question

marked as duplicate by MichaelT, GlenH7, GrandmasterB, Corbin March, Steven A. Lowe Sep 5 '13 at 16:47

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

11  
Personally, I'd fire them. –  TZHX Sep 5 '13 at 15:10
2  
Senior Developer? Does anyone else actually buy that title or can we just call him what he is: A poor teammate. –  Ampt Sep 5 '13 at 15:11
1  
I don't think that this satisfies the (admittedly high) community requirements for objectivity of questions on programmers. –  jwrush Sep 5 '13 at 15:14
2  
2  
The problem with questions that whine about co-workers is that we only have one side of the issue. –  GrandmasterB Sep 5 '13 at 15:37
show 9 more comments

3 Answers

up vote 7 down vote accepted

I document their activities, give them multiple written warnings, work with HR to create and implement an improvement plan, then I fire them.

edit

Since you're not the manager, the best you can do is document what you see (stick to facts) and forward to your manager once in a while. If any of your peers complain to you about this person, encourage them to also document & forward to the boss.

Having a stack of documented events from multiple peers is very helpful to the manager when it's time to take action.

share|improve this answer
    
This is a no brainer. It's one thing to deviate from standards when they affect only you (I.E. Using multiline comments instead of each line having a bunch of one line comments put together) but to actively tell others to deviate from the standard? That's asking for trouble. –  Ampt Sep 5 '13 at 15:13
add comment

Obviously, firing them or reporting them to management is an option; whether or not it would be my first choice as an option would depend on whether or not they're also a good developer.

It seems wrong-headed to send a very smart person packing just because they don't follow the process. Especially if you don't fully understand why they don't follow the process. I would suggest that instead of simply labeling this person as a renegade and looking for ways to deal with the person, you address each of the problematic behaviours one by one and look for ways to deal with those specific behaviours.

For instance:

  • Not committing things to source control is infuriating (as a lead, I've occasionally had to politely grill others about this) but sometimes it's hard to find alternatives, especially if you're using old-school centralized VCS where you only get one chance to fix merge conflicts and commit.

    When dealing with TFS or even SVN, before the git-tfs or git-svn plugins were stable, I would frequently have to make backups of my working copy just in case I messed up a merge. In companies where merge conflicts are difficult to resolve or broken builds aren't handled properly, delayed commits or no commits can be a defensive behaviour that points to higher-level organizational problems that need to be resolved.

    Not saying any of that applies to you or your teammate or your organization, the point is we don't know, and I assume you don't know either, otherwise you would probably have included that information in your question. (right?)

  • For problem #1 (using email for work assignment), the solution is blindingly obvious: Ignore them. I think the vast majority of developers have had to deal with this problem at one point, although the more common incarnation of the problem is business users making requests by email, as opposed to other developers/managers.

    It's basically the same situation, though. You ignore the email requests, and if pressed, you politely explain that your email comes in too fast and too frequently to be able to keep track of any issues or requests buried in there, and that you need it in the bug database in order to track your own time. Mention this to the Project Manager, assuming you have one; they will definitely take your side on it.

    I've found myself at the business end of this, too, when dealing with sysadmins; sometimes there's a blurry line between just asking a question on IM and requesting an investigation of some issue, and I'll get told to submit a ticket by emailing their tracking address. It's a minor inconvenience but it's really no big deal, I understand how their time is both highly compressed and under intense scrutiny, and they can't afford to be doing random stuff for random people without a priority attached.

In most cases, if there is a good reason for a process to exist, then it should be a simple matter for you to either register a formal complaint, or to simply follow the correct process yourself and let others deal with the consequences of not following it.

But, as I mentioned before, make sure that what you're complaining about is the specific process not being followed, don't word it as a general complaint about the person otherwise you'll almost certainly come out looking like the bad guy.

share|improve this answer
1  
+1 for ignoring the requests made by email. If you respond to requests made by email rather than through the official bug report mechanism, then you are failing to follow good practice, too. –  dan1111 Sep 5 '13 at 15:48
    
You can often use git together with an older VCS to help ease through tricky merges. –  David Plumpton Sep 12 '13 at 3:20
add comment

To encourage the usage of a bug tracking system instead of e-mails, you can use the same technique I've used with my customers. Create an automated e-mail explaining how to submit a bug or request a feature on a bug tracking system. Send this automated e-mail each time you receive a bug/feature request by mail.

Few days later, the person would be so annoyed that either he will confront you (beware of angry people), or start using the bug tracking system.

Similarly, ignore documents which are not stored in the official repository. If the person asks you why haven't you followed a specific document, ask which one, and tell that you never read it, since it's not in the repository.

share|improve this answer
    
I approve of the idea of sending out a courtesy email explaining how to submit an issue. It could be viewed as passive-aggressive, but then again, ignoring the email could be viewed that way too. A long time ago I had a manager who would periodically send emails reminding people about the process, but not surprisingly, it didn't help much; for many, all reason and rationality goes out the window when they actually have a problem, and they really need to be reminded at that exact time. –  Aaronaught Sep 5 '13 at 15:52
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.