What to do with subversive assholes that I have to work with?

Many, many months ago I started writing a program for work, this was to be an OS service, the details aren't really important. I got a good chunk of this done in C++. Then other, unrelated work was assigned to me and at this same time it was deemed that all that work should be rewritten in plain C. Since I didn't have the time for this the task of converting this to C and having the code merged with other components into a single process was handed off to someone else. A few weeks later the code changes were submitted. I looked through it, it was straightforward, objects eliminated body of the functions pretty much the same otherwise. The code wasn't really that involved. However all the comments in the source code the headers, the revision information all of it was removed from the original and updated with new dates, version numbers and a new author's name. This extended to the design document which was literally identical to the one I wrote and had updated except it now had a new file name had all the revision information removed and the version number rolled back to 1 and of course a new author's name, otherwise it was identical to the last version I wrote, down to the page numbers, section numbers and even the god damn font, really a complete rip.

I was then informed that he and I would be co-owners of this service. This is a bad idea at the best of times as people will invariable differ on an approach and without someone having authority over the other it's a stalemate. We're also on entirely different teams, I don't think we have a common superior until the VP level, and have a good thousand miles of physical distance between us. I knew immediately this was going to be a fucking nightmare with this guy. I've been able to minimize our interactions entirely, which is the only reason I've been able to stand this so long, by quickly dividing up areas of responsibility. This has worked pretty well, we don't have to communicate frequently at all. When we do though it's never been a good experience.

He's constantly undermining me, refusing to make any alterations during code reviews, no matter what or how small. It doesn't help that's he's a terrible coder. The only battle I sort of won was when he introduced a new thread as a means of handling an event when our process is specifically designed and intended to be single threaded and didn't even make attempts at making it thread safe at all. He of course did what he always does and submitted the code before the review was done and it lived in our code base for over a week while he refused to make changes I refused to sign off on the review. When he finally changed it his change was almost as poor as he used a signal handler instead and did all the work (seriously not trivial) in the handler and didn't do anything to protect any data within it and modifies the crap out of several pieces of externally accessible data. In this OS a signal handler processing stalls the kernel and can interrupt the process at any time. It can have very similar effects that an unsafe thread can, such as data changing between what appears to be sequential lines of code as the kernel may interrupt the process right then to execute the handler. His excuse for all this crap is constantly that his change absolutely has to be done now because it's needed for version X, even when the cut off for version X is weeks away.

Today he really got under my skin as he once again submitted code prior to even posting a review. Again the code is absolutely terrible, it's a total hack in the service to try and cope with a bug causing some odd behaviour in a related component. The change actually breaks the service should that related component be fixed. If that dependent component is changed and suddenly works as it's intended to our critical OS service no longer functions. He's refusing to change it, one of his secondary responsibilities is even that dependent service, he can correct the root issue he just doesn't want to. He spent all day fighting this, as of course it's needed by the end of the week, instead of acknowledging the issue and using the time to implement an actual fix. I like my manager but it seems he's more interested in trying to keep people happy than do what's right, even when though our technical lead is always on my side, I don't push the issue if he's not. I've pretty much had to capitulate every single time just to keep this supposed relationship on good terms, which it clearly isn't.

I don't know what to do with this ass, frankly I just don't want to have to deal with him anymore and would like to just wash my hands of the whole thing and give up ownership of this service. It's just not worth it and it's disheartening seeing it get progressively worse as time goes on. Anyone have any suggestions here?

You have a few options:

1) Figure out what he needs to stop dicking with you.
2) Firewall him off from your work somehow.
3) Get him or you transferred.
4) Get him fired or disciplined.
5) Get a new job.

Dealing with passive aggressive coders is completely exasperating. I've never found a good solution other than "make sure it's all their fault when the shit goes down."

Seriously. BCC a relevant party on a message to him saying "If you do this and they fix X, it will break again," and hopefully they'll fix X, you'll have documentation of being right, and you can use it as leverage for whatever.

Your conflict avoidance is showing. You forgot the most obvious, effective, and satisfying option:

6) Repeatedly call him out on his shit, preferably in public emails with as many people as possible cc'ed. Demonstrarte, through careful reasoning spiced with professional insults, how terrible he is. Do it repeatedly. Do it every. fucking. time. he pulls shit. Argue with him every step of the way. It actually doesn't take that much time, although it does take energy. Eventually they start to either toe the line, or they themselves start suggesting ways to limit the interaction. There's nothing quite as effective against passive aggressive douchebags as simply making it an actual aggressive situation. They hate that shit... that's why they go "passive" in the first place. And they tend to get worked up & emotional about it, and so they tend to make mistakes in the conflict.

I've successfully done this approach several times, and it works pretty well. You end up making a lifelong enemy, but who the fuck cares? He's an ass.

I suppose if you work in a team full of head-on conflict loving people that'd work, but I've never seen that. You tend to get flagged as a "problem" otherwise.

No, as long as you make it clear why what he's proposing will cause problems, the other people generally start getting exasperated with the other guy's shenanigans. You do have to phrase it right, and make it look like you're doing it for the good of the company and mankind, not because of a personal vendetta. Also, you need to use the "cc" function judiciously. A lot of arguments about specific positions are best handled as private communications. It also helps to involve your manager early and explain to him (or her) the steps you're taking to mitigate the potential damage the asshole is doing.

In short, you proactively portray yourself as a problem solver, before the problem even arrives. Isn't that awesome? Everybody loves that shit. Except the guy you're needling, of course.

By "other people" do you mean his management chain? No one else gets a vote. Unless they decide he's a bigger problem than you, and are willing to act on it rather than smooth it over, it doesn't really accomplish much. Specifically, this sort of thing is going to get you flagged as not a team player in my judgement, and it'll rapidly become "why are you such a dick" rather than his issues:

You can do this professionally and what not and yeah, it'd work, but that's not the vibe I was getting.

As to passive aggression, I just assumed from the context of the original post that management intervention wasn't a viable route and made recommendations based on that.

I don't know what "other people" you're talking about. I mentioned other people several times.

And it's not about getting other people to smooth something over. It's about making the programmer miserable and unhappy with the situation. Public embarrassment tends to do that with most people. That's why the "cc" function is often helpful. But the public embarrassment angle is only part of it; some people are immune to that. The real thrust of this whole thing is to fight with the asshole, and in the process make him miserable.

Like I said, I did it many times, and it worked. Sure, people thought I was a dick, but I was an effective (and often amusing) dick that got things done.

Seems like the root of the issue is over control, both you and him believe that you should be the sole 'owner' of the service. First you need to examine your own priorities and workload, if you really don't have time to be maintaining the service full time then I would suggest you should just learn to let it go because no matter how good you are you can't do everything. Make it clear to your manager that you don't have time to maintain the service with your other responsibilities and that you want your ownership over the service removed by X date.

Alternately, If you actually do have the time to maintain it full-time then I suggest you make a polite ultimatum to whoever determines responsibility for maintaining the service. Let them know that the shared ownership isn't working out due to a personality clash that is too difficult and time consuming to resolve and that either you get back complete control of maintaining the service or you want to no longer be responsible for it by X date.

I think that should be the goal; polite and professional but still firm with your management. If either of those options are refused then you definitely have a wider management problem than just the issues with this one distant staff member.

I've tried the public shaming approach though not with that intention as I pretty much don't email him without both his and my manager on the CC list, though mostly that's to cover my own ass.

The division of ownership isn't due to workload it's because this service operates on two platforms, he's the specialist on one and I'm the specialist on the other, so it's to ensure both platforms are covered. This isn't really that significant though as the difference in hardware are for the most part abstracted out. This service is supposed to be the last part of that abstraction and is binary compatible with both platforms. In reality we almost never run into platform specific issues, mostly platform issues come down to behavioural difference in the other component I mentioned which are platform specific (one binary for mine a different binary for his) and these differences rarely have anything to do with the actual platform are just differences in implementation between the two. My services isn't the only one operating with this co-ownership based on platform approach. Personally I don't think it's even necessary as these services are a couple layers above the actual platform specifics and a single owner/team would work fine, whatever it's a structural oddity of the company.

I don't much care about being the sole owner of the service I just want someone I can work with who isn't actively undermining and dismissing me. I want someone that doesn't fight me when I point out that they're spawning a thread in a process that is intended to be single threaded and haven't made anything thread safe, someone that doesn't unilaterally submit code before the code review is complete, or even posted! He's simply unreasonable.

Unfortunately, it sounds like having him fired and replaced isn't within your sphere of control at the company or else you already would have done it. Nor is it within your control to make him a reformed character. I suspect the only area where you do have a solid chance to control the situation is in your involvement with him as I outlined above. From what you've described your, or his, involvement doesn't seem 'essential' to the continuing functioning of the service (they could replace you or him with another platform specialist and as you say the service doesn't really require two platform specialists anyway).

You may get lucky and find, that by informing your management that the situation is bad enough that you want to get away from maintenance of the service just to avoid interacting with the staff member, that he ends up getting fired at some point down the line anyway. Thereby forever sparing you the possibility of interacting with him in the future.

I'd have to agree with Jason here - doing what Mark suggests would just get you flagged as "not a team player" at Microsoft.

Anyway, back to the subject at hand - go find a new job. If your manager isn't willing to help you against annoying assholes like this so they can keep the peace, they likely will throw you under a bus to keep the peace as well. I learned the hard way that sticking around through a bad manager because you like the job is a Bad Idea (TM).

I don't think my manager is bad but I don't think there's much he can do other than inform my counterpart's manager or move me off the service. As I said he and I don't share a superior until we get into the executive layer of the company and they're not going to give a crap what's going on in the trenches (nor should they).

Wouldn't the appropriate course of action, then, be for your manager to contact his manager, and make it clear that he's disruptive, impeding progress, damaging the service, and refusing to execute on his responsibilities, such that it is materially damaging the entire project? Or do you have reason to believe his manager won't take action, or your manager won't convey the facts of the problem? If so, either get your ass off the project or document - repeatedly, clearly, and permanently, your attempts to solve its problems, such that when it crashes and burns, it doesn't take you with it. Yelling at him, shaming him, etc - you're just a name and some text on emails from across the country. You have very little ability to directly impact him, from what you've described of the situation.

Maybe you need to ask him that, though, rather than making his decision for him? From what I understand, it sounds like you're fully in the right on this, so it's not like you need to be concerned about blowback. Frame it in such a way that you're bringing this up because you're concerned about the project due to your coworker's shoddy coding, tendency to ignore code reviews and other (presumably necessary) practices, and overall responses to your concerns regarding the service for which you're responsible.

Be proactive. Stop avoiding or minimizing interaction, that's only hurting your case. Whether you like it or not, you're effectively in charge of this project due to the fact that you're the better and more conscientious programmer. If you approach management with concerns about the project (rather than complaining about a coworker or indulging in "poor me" whining about your situation), you may get better results than coming in with an ugly personnel situation that nobody wants to deal with. Don't be a tattle-tale - again, this is about the viability of the project, because it's in everyone's best interests that this project is successful - and document everything in writing.

But you have to be proactive about resolving this, without being negative or bitchy. Be upbeat and offer solutions rather than creating problems (to management, "I'm unhappy with X person" is a problem that they don't want to deal with). So far it sounds like you've either avoided this situation as much as possible or been reactive to your colleague's poor work - you need to turn that around if you're going to resolve this.

These seem like solid objections to point out to your manager along with suggestion the guy doesn't appear to have what it takes to be in position he's been placed (and so that maybe it's in company's best interest to either pressure him to shape up or re-assign him to a position more compatible with his limited abilities) Have you done that? What was the manager's response if so?

Oh, I guess that would work, yeah. Personally I've found these guys always have a higher tolerance for rolling in shit than you have for throwing them into the pig pen.

Do you have an official or unofficial policy that all code must go through review? If so, this is a golden gift.

What shall we do with subversive assholes,
What shall we do with subversive assholes,
What shall we do with subversive assholes
Early in the morning.

Microsoft is where I worked for 8+ years, and it's where the tactic was highly effective. And I ended up leaving not because I was flagged a problem child, but because I personally got tired of Microsoft. Yes, the pay checks were nice (and large), but I got tired of working on an endless parade of widgets I didn't care about.

Things have changed :)

In the past year? I only left 15 months ago.

They certainly have in my group. The culture you describe was the norm 3 -4 years ago, but not so much anymore.

Wow. I'm even more glad I left, then. It was the ability to resolve things by being upfront with problems that I liked the most about MSFT. Getting flagged as a problem simply because you make issues public is something I expect from Generic Corporate Culture in America. That was one area where Microsft was a cut above the rest. It sounds like they're descending to the level of other corporations. How sad.

Still, the fat paycheck *was* nice. I guess if that's your top priority, they're still top notch.

BTW, your timeline does jibe fairly well with my experiences. The last year or two I was there, I was pretty disengaged because I was so sick of it. I could very easily believe that the culture had changed during that period w/out me noticing.

This is getting messy. I just did a quick audit of code reviews and code submissions. It's even worse than I thought. Now there's debate at the management level about all this. Maybe it is time for me to just GTFO.

You can play games with commit hooks to freeze submissions pending review in a lot of source control systems. But that's usually going to piss everyone off in smaller teams where you can't play it as "well, it's to keep other people from messing with your work!"

But really, this needs to be solved by some managers stepping in and doing what they are supposed to do. The shitty part of management where you have to tell someone to stop acting like a dick at work.

What the hell is the debate about? How much the other guy sucks? Or how you're being mean to him for checking on his work and finding out he sucks?

Go for the worst case: "Why do we even DO code review?!"

One thing I've learned (and am still working on) in a pretty tumultuous career is that it is always more effective to communicate why a conflict harms the company than it is to bring personal baggage into it. The personal baggage is there anyway and everyone knows it, but when you show management why it is costing them money (time, energy, resources, all those equal MONEY) then you will have a case.

I would document all of the problems with his code, how they are causing bugs or additional work or whatever else, and why this is costing money. I would also document the technical rationales on why the various framework problems he's introducing (such as non thread-safe code) is going to cost money either through future work on patches or on dissatisfied customers.

You show a manager how it hits his department/personal pocketbook and he will listen. Your manager, his manager, the shared VP, whatever. Because the answer to personality conflicts is "deal with it/get along/too bad/find another job" but the answer to losing money is "holy shit I won't get a bonus this year" and that gets their attention and interest, leading to making a decision and then finally taking action. A. I. D. A.

Get mad you sons of bitches!

(yes I have been posting/referring to this clip alot lately)

Every time I've seen this happen - and it has been a few times now - the guy doing what you suggest 'wins' the short term fight and then oh whoops he just happens to be in the layoff next time around.

Apparently there's some misunderstanding somewhere about what the relationship is between he and I and who owns the code. Our managers seem to have a disagreement. If anything else has gone on it's gone on offline.

I reported the results of my audit to my manager, there are about 8 or so incidents of him submitting code either without a completed review or before the review was completed. Also an incident of submitting code without a review at all. At least this is now in my manager's court, he says he's spoken his manager though I have no idea about the details.

The company is generally very short term focused, the quality of the change seems to be lost on people, even my manager. I told him that this latest change as currently implemented WILL break the code once planned changes go in after Christmas or could break if the bug this change is trying to cope with is fixed. His opinion was that it was a change that currently only affects their platform and if they make a change that breaks it it's their issue and that since our platform currently works with or without the change we should just leave it alone. As someone who's responsible for the code that goes into the service I don't feel comfortable with that and really don't like that it WILL affect our platform in the near future. It still isn't clear what will happen at that point if they don't actually fix the bug that their change is working around and will as their shit will just be broken again. I can see us getting into the situation where their platform only works with the change but ours will only work without it, that will be a fun time. Whatever, stupid shit is in, I'm not signing off on the review though. Also I got a report this evening of a bug which seems to have the same symptoms as if this change were affecting our platform, but that symptom can be triggered in several different ways.

There you go, giving a fuck when it ain't your turn to give a fuck.

Part of the issue seems to be that the team structure as designed is doomed to failure. You have two people with two different management chains working on the same project. This only turns out well if the management chains link up maybe two hops above so everyone is by nearly on the same page. From my experience management chains are like a game of telephone, and the farther away you are from someone else the more they'll only slightly understand or care what you're trying to do.

I this case you are pleading about possible issues with your manager, and can be sure that if this is known he is pleading about how you're fucking up the code and/or preventing feature releases based on phantom problems with his manager. And this will play up the chain until it finally lands on the desk of someone who is nominally responsible for both of you and can do something about it.

Pretty much, I'm well aware that the structure is stupid. Most of the people on my team have counterparts on the other platform, though most others seem much better to deal with than mine. It's really silly, particularly because the division based on platform isn't particular significant, there really don't need to be any counterparts as long as there's good communication between us (the services folks) and the actual platform specific teams.

Keep your inventory of fucks as low as possible, preferably zero. Then you simply won't have any to give.

I think it's high time that we were given an epilogue.

Not much to say really, the emails that indicated our two managers had different ideas about our roles was the last. I inquired about it with my manager but then Christmas happened (literally, less than an hour later we both left for the holidays) and nothing more has come of it. The review is still sitting there unapproved and the silly code change was submitted. I think I've covered my ass with this, though I foresee myself making a change my counterpart may not approve of soon, as it removes the offending threading I mentioned above and replaces it with a single threaded solution. We'll see, he's been more open to my changes to his code than he has been to me logging bugs in reviews.