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.

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

share|improve this question

closed as off topic by Mark Trapp, JeffO, chrisaycock, Caleb, rjzii May 9 '12 at 23:27

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

This isn't really on topic for Programmers, our scope is problems that are solvable by, well, programming ;) It might be on topic for our sister site The Workplace, I've asked the moderators there to take a look. If it is indeed on topic for them, we'll move the question automatically, please don't cross post. –  Yannis May 9 '12 at 22:20
That said, what you've clashed with your co-worker about is on topic, perhaps you should consider asking about that instead. We can't help you win the argument, or gain favour with management, but we can verify whether what you consider good design / documentation actually is. Not saying that it isn't, but you never know. –  Yannis May 9 '12 at 22:22
You failed from the beginning to be useful to your manager. If he needs you to take on technical debt to make his job easier, live with it. Now someone comes along and copies your good work and gets credit. What were you waiting for? –  JeffO May 9 '12 at 22:58
dilbert.com/fast/2006-11-05 –  gbjbaanb May 9 '12 at 23:27
if he is bullying you, the only answer is to first talk to your manager about the situation, keep a diary of everytime he undermines or stabs you, then go to HR and make a formal complaint. You'll have to justify yourself fully, but if you can and they do nothing you'll have grounds for a payoff which will help as you recover to get ready for your next job. –  gbjbaanb May 9 '12 at 23:31

3 Answers 3

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
Pointing out the transgressions of others is akin to character assassination too. You can't be better than your peers if you pick up their tools and try to out-do them at their game. –  Edwin Buck Sep 12 '12 at 19:23

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