How to work in an environment with a 'character assasin' [closed]

Question

This is hard to explain, so I will start with my background. I have been in development for about 8 years (6 commercial), have a MSc in OO Info Systems, have a true passion for development and up until a year ago would spend most of my time learning new things and creating helpful applications for the team.

I work at a large investment banking company and this new developer who used to work for one of the larger investment banks joins the team, lots more experience than me, more professional etc... etc...

Initially I helped him out when he started (ALOT), my attitude up until recently is a team effort everyone helping each other out, but I think he saw this as a weakness. I was the big cheese up until he arrived, and in hindsight and in present time he now is.

We clashed because I take the object-oriented route and focus on good design / documentation etc... whereas he prefers not to do documentation and sort of hates OO prinicples, he would rather create a nice interface than good code, next to no comments, doesn't like unit tests, doesn't like interfaces/abstract/inheritance etc. The problem is what he is good at is pleasing management and I have to give credit where credit is due.

Now after 6 months he tried to always surpass me, take my code ideas and call them himself, snipe behind my back etc.. and eventually won favour with the developers and increasingly began criticsing me.

I'm now at the point where I am very stressed out because everyone has become hyper-critical of my code but when he or someone else makes a mistake or an error its quickly forgotten. Ergo the pressure is very much with me.

I'm not used to this situation and wondered if someone out there has come across this and has advice on how to tackle this situation? Or can share a similar experience that might be useful

Answer 1

I'll address the obviously bad behavior first, the stealing of ideas, excess and unbalanced criticism, etc...

• Communicate your ideas in writing, ideally e-mails with managers CC'd.
• Respond to complaints, in writing, ideally with CC'd managers as appropriate.
• Document examples of other devs making similar mistakes without the repercussions you're encountering, you got it, in writing, ideally e-mails to yourself with version control references so people can see the problems caused/solved along with reactions to your own mistake you found disproportionate. Bring the issue to the attention of your team in the form of discussion when you have a fair bit documented and failing sympathy there, bring the documented stuff to management.

That said, I suspect there may be more to this and I'm going to make some assumptions based on a between-the-lines reading of your issue. I have no idea how accurate these are but a couple things struck me as odd like the complete respect 180 from the rest of the team.

I'm guessing he's a self-documenter who writes to an interface, who could care less about the performance or ease of reverse-engineering of the guts of his objects.

I'm guessing maybe you're the guy who has everything charted and plotted to the letter on whiteboards and UML diagrams before you even start a new project in your IDE and all your stuff is hyper-carefully crafted.

I'm guessing what management likes is that he gets stuff done faster than you.

I'm guessing the other devs might like working with his code better than they like working with yours since you've mentioned his focus on interface over underlying code quality. I find it hard to believe they'd rally around somebody who made their lives more difficult or the codebase a big giant mess.

If I'm at least a little bit right, you may need to evolve a bit as a dev yourself. Is it just this guy you've butted heads with on your approach to development or is he the only one who refused to back down? At the end of the day, is his code any less robust or harder to work with than yours because of his approach to it? If you can't honestly say yes, you may want to revisit whether you aren't blindly adopting patterns and best practices without consideration for context or the full scope of the problem to be solved or how easy the results are to work with. Ask the other devs what they think about the guy's code compared to yours. You might be able to beat him at his own game while benefiting from the higher standards you have for what's under the hood, unless those standards are overly arbitrary.

And of course this may simply be office politics at its worst. If that's the case, do you really want to be in a work environment where that kind of toxicity is allowed to carry on? Cover your butt as per above, but it's plan B time if there's no truth to my speculation and you've simply stepped on a hive of angry douchebags with a new queen bee.

Answer 2

I'm in a situation like that right now. One of my teammates suddenly turned on me in fact. I tried very hard to work with the others on my team, provided all the ideas I had openly, etc... When I wasn't given something to work on I would come up with something on my own. When I saw a need to work out a proof-of-concept I threw one together in a week and sent it up the chain. I took initiative in a situation where I wasn't being given anything to do at all and tried to get stuff accomplished.

It back fired big time. My teammate who'd repeatedly told me he liked the code I was making and found me easy to work with freaked out one day while I was sick...stuck a billion bad comments in my code reviews, and tried to get me fired. The team lead lied about me, said he'd told me something he never did, etc...

I have a new manager now, but the shit is all over the walls. I don't really hold out much hope. I'm putting my resume together, breaking out the new stuff at home...and looking for ways to remarket myself to someone else. Heavily considering going off on my own.

Answer 3

Be flawless. Raise a shedload of bugs that you find in this person's code (and the same for other co-workers) and encourage people to do the same to yours. Stay professional. Find what you're good at and harvest it. Find what you're bad at and work on it.

When your co-worker falls afoul, point to his code coverage, or to his massive sloppy commits that make finding regressions difficult, first in private and then in public if you think he's not acting on it. Don't be smug about that though.

Make sure you do the same to the others, and be prepared to back up what you think they should be doing but aren't with numbers, with informal training sessions or even with direct help.

If, for example, Test Driven Development is something you want to drive, make sure you have feasible answers for anything that you do that might be difficult to do via TDD (UIs, links with databases, manual steps in processes, etc.).

All that said, keep your own work going so that you're not the office busybody who never gets anything done.