4

I am a programmer working for a Tech company.

There is a colleague of mine who I work with on different projects. When working with him I've noticed a bothering trend that appears to be a very successful manipulative pattern he uses.

It starts the same. We start with full cooperation and both work hard on the project. Our contributions at this stage are about 50/50. That is when we develop core functionality of a system. Then a field of additional interesting features opens up and usually each of us choses own path.

Later on, if he sees that I've implemented something valuable, he just analyzes how I did this and after some time secretly re-implements it from scratch with very minor changes or additions. That all in addition to his standard contributions and probably in free time / overtime.

After that, he claims this feature and work as his own: in meetings, documentation and email communication. Usually, I know that he is doing it from scratch by the time he accomplishes about 80% - 90%. Clever thought out.

Basically, he makes me go through the hard path of discovery and first-hand experience, then after understanding where the path lies, he simply does it himself from zero.

With time, as the amount of such softly "stolen" features accumulates, he claims major role / major contribution in a project and reacts very jealousy of any external communication from my side concerning the project.

What can I do to stop this type of "cooperation" in a professional way?

  • 7
    Doesn't your version/source control show history? Therefore showing your work and effort. – Steve Jan 27 at 20:48
  • Not all of the work is in form of code. But even though some stuff is in a repo, managers don't bother to look or care. Most of the stuff they will not even understand. – Eval Jan 27 at 20:50
  • 2
    If you've already implemented a feature, why would we reimplement it from scratch? How does he justify that? It seems like he would have to say something like "Well, even though Eval has already basically got something working, I decided to reimplement it because of <insert reason here>." – Brandin Jan 27 at 22:19
  • 1
    What prevents you from starting using a code repository in small projects? Why not enlisting the help of your manager on solving this? – Rui F Ribeiro Jan 27 at 22:20
  • 1
    Possible duplicate of How to deal with someone taking all the credit – gnat Jan 27 at 22:50
7

I would turn this "secret collaboration" into a real one. The simple fact of the matter is that you guys are a team. If one person is implementing something another can use, you are supposed to share it. Not only that, if he takes something of yours and improves it, he's supposed to share it back. Not secretly accumulate such code until he's ready to unleash it as his own.

This is just plain business sense. You can't have developers hiding useful code from each other. The whole can only be greater than the sum of its parts if you build on each other's code.

As you say, you are on a team of two without the formalized procedures of the rest of the company. I would semi-formalize such procedures for yourself. Code review is not needed. Just raise the point at a meeting that there is a lot of code duplication going on. Point out that your colleague took an example of your code and made it much greater and it would have been useful for you two to have combined efforts on it. Not only that, point out the danger of having duplicate functionality scattered through the codebase.

Once your manager(s) have agreed to this tacitly (not objecting is acceptance!), for the coup de grace, start putting functionality that seems useful to share into a common library and updating your boss on this progress. The important thing is to put anything your colleague might steal into this library. If he doesn't build upon it, but uses the code somewhere else, now it is an issue you can bring up at a meeting.

  • 1
    That is one possibility. However, I'm 100% sure he'll act in a passive-aggressive way if I inform management of my work on a regular basis. He considers that I "steal credit" and hijack the project this way. The guy is ultra competitive and it stems from previous projects he did with some people, where others got promoted but not him. So its a mixture of insecurity and sneakiness of character ... – Eval Jan 27 at 22:39
  • 2
    @Eval: All you can do is stay above board with your work and report any issues (such as misbehavior from your coworker). If your colleague decides to be counterproductive, actively ruin your morale, or anything else, that is on them. – Flater Jan 28 at 9:48
2

He just analyzes how I did this and after some time secretly re-implements it from scratch with very minor changes or additions.

The answer here has to be Code review.

Incorporate it into your workflow, then there's no "secret code" being committed. (The fact someone can commit code in semi-secret is kind of an issue in itself.)

He then has to work in a branch and have his re-implementation signed off by at least one other developer before pushing to master. If he tries to get weird re-implementations for no clear reason signed off with minor changes, then that will immediately raise red flags to any half-competent reviewer.

If you really can't persuade your team to move to code reviews officially, then do it unofficially. Keep an eye on all commits (set up post-commit notifications if you haven't already), then if you see your colleague re-implementing large chunks of work for no reason, call him out on it:

Hey Bob, I noticed there's a large commit you made outside of working hours which makes a lot of changes to x functionality that I can't get my head around. Can we discuss this so I can understand why these changes were necessary?

Keep doing the above, and one of a few things will happen:

  • He'll realise he can't do these things in "secret" anymore, and stop
  • He'll refuse to discuss it with you and keep re-implementing your code for no reason, in which case you then have a paper trail to take to your manager and ask him to find out wha'ts going on
  • He'll meet with you and explain the changes that he made, you might realise they were beneficial or see his thinking, and you clear up a whole misunderstanding.
  • Our company doesn't conduct the development in this way in the small projects I work on with my colleague. Bigger projects do have the mentioned processes. I am in a group of two (me and him) in a given project. The management does not require a code review and will not perform it even if I ask. They lack competence ("people's" managers) for it and have no additional resource to assign this task to. The only way to get it done is to complain and escalate, which I want to avoid as it would do me no favor. – Eval Jan 27 at 21:10
  • 2
    So, do the research. Google around and prove how much code review (and unit test) benefit a project and how it takes longer and costs more to finish if you don't. There is a ton of evidence out there. – Mawg Jan 28 at 8:46

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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