-1

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
NWS
  • 1,319
  • 8
  • 17
  • 11
    Personally, I'd fire them. – TZHX Sep 05 '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 05 '13 at 15:11
  • @TZHX Personally i would too... – NWS Sep 05 '13 at 15:12
  • @NWS Then do so. – TZHX Sep 05 '13 at 15:12
  • 1
    I don't think that this satisfies the (admittedly high) community requirements for objectivity of questions on programmers. – jwrush Sep 05 '13 at 15:14
  • @TZHX ... But im not their manager :( – NWS Sep 05 '13 at 15:14
  • I'm beginning to think that the title "senior" is now incorrectly implying higher knowledge of their field (given the word's conversational meaning)... – Katana314 Sep 05 '13 at 15:14
  • 2
    possible duplicate of [Is cowboy programming a senior approach?](http://programmers.stackexchange.com/questions/83167/is-cowboy-programming-a-senior-approach) / [Frankly, do you prefer Cowboy coding?](http://programmers.stackexchange.com/questions/7217/frankly-do-you-prefer-cowboy-coding) / [How do you disarm a cowboy coder?](http://programmers.stackexchange.com/questions/157251/how-do-you-disarm-a-cowboy-coder) – gnat Sep 05 '13 at 15:15
  • @NWS I think the answer to this question depends on how the issue affects you. – dcaswell Sep 05 '13 at 15:35
  • 2
    The problem with questions that whine about co-workers is that we only have one side of the issue. – GrandmasterB Sep 05 '13 at 15:37
  • @user814064 mostly it just annoys me. – NWS Sep 05 '13 at 15:37
  • `Why does my company have processes and not care if they are followed?`. Unfortunately that's way too common in our field. – dcaswell Sep 05 '13 at 15:40
  • I actually disagree with the close votes for once. It's true that the question is a little ranty and should be re-worded, but this really isn't a question about "cowboy coding", it's about specific processes that aren't being followed, neither of which have any mention in the duplicates. Also, we're not supposed to close as duplicates of questions which are themselves closed. – Aaronaught Sep 05 '13 at 18:31
  • @GrandmasterB - Sorry if the Q came across as whiny. Yes there is only one half described here, but i can assure you that i am not the only one who has the problem with this senior citizen. – NWS Sep 09 '13 at 08:52

3 Answers3

8

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.

Aaronaught
  • 44,005
  • 10
  • 92
  • 126
  • 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. –  Sep 05 '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 03:20
7

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.

Dan Pichelman
  • 13,773
  • 8
  • 42
  • 73
  • 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 05 '13 at 15:13
5

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.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 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 05 '13 at 15:52