Skip to main content
added 1031 characters in body
Source Link
berry120
  • 34.8k
  • 20
  • 91
  • 127

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.

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.

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.
Source Link
berry120
  • 34.8k
  • 20
  • 91
  • 127

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.