How to deal with my colleague copying my work?

Question

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?

Answer 1

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.

Answer 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.

Answer 3

After you have exhausted all other paths -- making your managers aware of the problem, confronting your imitator, recording the early part of your implementation -- then it is time to set the trap.

When you implement a feature, figure out the best approach and the worst approach. Research the worst approach where your colleague can see it, and implement your best approach privately.

When he presents your work as his, immediately present your superior solution.

Repeat as necessary.