Respecting Fellow Developers [closed]

Question

We've all been there. You have written some code and unit tests, the tests all pass, and the code is decent (nothing's perfect, right?). Then, someone who is sure that they know better than you comes along and decides to change your code or the interfaces to your code just because he/she does not like the variable/class names that you used. No "real" refactorings, no real optimizations, no real improvement -- just different words -- not necessarily better words, just different.

My real problem with this is that (a) its a waste of time and (b) it shows a blatant disrespect for the fellow developer that wrote the code in the first place.

My visceral response is to lash out, but that's counter productive. Instead, I though that I might wright a paragraph or two as sort of a "Charter" or "Philosophy" that is adopted for the project. I'm wondering if anyone else has tried this, and if so, was it successful?

After looking at the initial comments below (which are appreciated), I think that my problem is primarily that this change broke the build for code that was already working. So time needed to be spent to fix the code for what was (in my opinion) a non value-added change.

-- Thanks

Answer 1

...decides to change your code or the interfaces to your code just because he/she does not like the variable/class names that you used.

My real problem with this is that (a) its a waste of time and (b) it shows a blatant disrespect for the fellow developer that wrote the code in the first place.

My visceral response is to lash out...

I see some VERY CONCERNING things in those statements.

1. naming is REALLY, REALLY important. It is worth rewriting code to get it correct.
2. It is not YOUR code
3. How is it disrespectful?

You are taking it too personally.

I once worked with someone who freaked out when I made changes to "his" code. His code as horrible; it was buggy and unmaintainable. He was always staying late, fighting fires and breaking things - basically a negative contributor. I rewrote all his bad code for a big piece of functionality for a project one weekend and when he came back in on monday had a hissy fit. I am not saying your stuff is horrible, but maybe you need to calm down and be more objective about it.

Don't take it so personally. Step back and think about it - maybe "your" code needed fixing

We might be able to give better answers if you posted the code and changes, or at least some better idea of the situation with an example or two.

EDIT: After seeing the code change and finding out that the build was broken, I am going to have to change the tone of this answer. I understand Steve's frustration - and i agree - that is not a good change. It makes a specific typedef more general and not very descriptive any more.

While I think some of my points are valid, in this case it looks like the changes were not appropriate.

The issue of code "ownership" is irrelevant. If the code changes are useless then everyone on the team should not be happy. If they are good changes then everyone should be happy about it. If there is a difference of opinion then you all need to find a common ground.

Breaking the build is not a good thing.

Steve, sorry if I came down harsh - it looks like in this instance you are justified in your frustration, but not because it is "your" code.

Answer 2

One thing that might help in this sort of situation is to require code reviews for all changes. People are less likely to make pointless changes if someone else has to review it first. If they can actually convince another developer that their change should go in then maybe it isn't so pointless after all.