Return to Answer

You've already reversed the changes. So let it go.

That being said, the next time this happens. Be sure that there is no wiggle room with your interpretation of the coding conventions. Because, if you're going to have a battle with someone, be sure to pick a battle that you have a 100% chance of winning.

This is important especially if you do not have as much social capital with management as this person has already.

Also, be sure to add unit tests before you modify too much of his code. If you introduce bugs to his code, you will never hear the end of it. And when you do find something of his that is worthwhile for you to change. Then, go ahead, but be careful and follow the official conventions (and if not the official conventions don't address a particular issue, follow the Code Complete conventions at least).

If he does complain to you, then you can just tell him to fight on changing the code conventions, and that once he receives approval for those new coding conventions he has in mind, that you will be glad to take a look at them and implement them, but not before then.

Also, you should probably ask management to organize weekly code reviews. After all, if you have a chance to discuss coding decisions during code reviews. It will give you a safer and less confrontational way to understand and/or challenge some of your peers bad habits.

You've already reversed the changes. So let it go.

That being said, the next time this happens. Be sure that there is no wiggle room with your interpretation of the coding conventions. Because, if you're going to have a battle with someone, be sure to pick a battle that you have 100% chance of winning.

This is important especially if you do not have as much social capital with management as this person has already.

Also, be sure to add unit tests before you modify too much of his code. If you introduce bugs to his code, you will never hear the end of it. And when you do find something of his that is worthwhile for you to change. Then, go ahead, but be careful and follow the official conventions (and if not the official conventions don't address a particular issue, follow the Code Complete conventions at least).

If he does complain to you, then you can just tell him to fight on changing the code conventions, and that once he receives approval for those new coding conventions he has in mind, that you will be glad to take a look at them and implement them, but not before then.

Also, you should probably ask management to organize weekly code reviews. After all, if you have a chance to discuss coding decisions during code reviews. It will give you a safer and less confrontational way to understand and/or challenge some of your peers bad habits.

You've already reversed the changes. So let it go.

That being said, the next time this happens. Be sure that there is no wiggle room with your interpretation of the coding conventions. Because, if you're going to have a battle with someone, be sure to pick a battle that you have a 100% chance of winning.

This is important especially if you do not have as much social capital with management as this person has already.

Also, be sure to add unit tests before you modify too much of his code. If you introduce bugs to his code, you will never hear the end of it. And when you do find something of his that is worthwhile for you to change. Then, go ahead, but be careful and follow the official conventions (and if not the official conventions don't address a particular issue, follow the Code Complete conventions.

If he does complain to you, then you can just tell him to fight on changing the code conventions, and that once he receives approval for those new coding conventions he has in mind, that you will be glad to take a look at them and implement them, but not before then.

Also, you should probably ask management to organize weekly code reviews. After all, if you have a chance to discuss coding decisions during code reviews. It will give you a safer and less confrontational way to understand and/or challenge some of your peers bad habits.

You've already reversed the changes. So let it go.

That being said, the next time this happens. Be sure that there is no wiggle room with your interpretation of the coding conventions. Because, if you're going to have a battle with someone, be sure to pick a battle that you have a 100% chance of winning.

This is important especially if you do not have as much social capital with management as this person has already.

Also, be sure to add unit tests before you modify too much of his code. If you introduce bugs to his code, you will never hear the end of it. And when you do find something of his that is worthwhile for you to change. Then, go ahead, but be careful and follow the official conventions (and if not the official conventions don't address a particular issue, follow the Code Complete conventions at least).

If he does complain to you, then you can just tell him to fight on changing the code conventions, and that once he receives approval for those new coding conventions he has in mind, that you will be glad to take a look at them and implement them, but not before then.

Also, you should probably ask management to organize weekly code reviews. After all, if you have a chance to discuss coding decisions during code reviews. It will give you a safer and less confrontational way to understand and/or challenge some of your peers bad habits.

You've already reversed the changes. So let it go.

That being said, the next time this happens. Be sure that there is no wiggle room with your interpretation of the coding conventions. Because, if you're going to have a battle with someone, be sure to pick a battle that you have a 100% chance of winning.

This is important especially if you do not have as much social capital with management as this person has already.

And so, take your time, get familiar with the code base. Once you find something worthwhile that you can change about his code that he can't complain about. And once you have nothing else more important to do. Then, do it.

And if he does complain to you, then you can just tell him to fight on changing the code conventions, and that once he receives approval for those new coding conventions he has in mind, that you will be glad to take a look at them and implement them, but not before then.

And if the argument is about something that is not written in the code conventions, bring a copy of Code Complete 2nd edition to work and use that as your final arbiter.

Also, you should probably ask management to organize weekly code reviews. After all, if you have a chance to discuss coding decisions during code reviews. It will give you a safer and less confrontational way to understand and/or challenge some of your peers bad habits.

You've already reversed the changes. So let it go.

That being said, the next time this happens. Be sure that there is no wiggle room with your interpretation of the coding conventions. Because, if you're going to have a battle with someone, be sure to pick a battle that you have a 100% chance of winning.

This is important especially if you do not have as much social capital with management as this person has already.

Also, be sure to add unit tests before you modify too much of his code. If you introduce bugs to his code, you will never hear the end of it. And when you do find something of his that is worthwhile for you to change. Then, go ahead, but be careful and follow the official conventions (and if not the official conventions don't address a particular issue, follow the Code Complete conventions.

If he does complain to you, then you can just tell him to fight on changing the code conventions, and that once he receives approval for those new coding conventions he has in mind, that you will be glad to take a look at them and implement them, but not before then.

Also, you should probably ask management to organize weekly code reviews. After all, if you have a chance to discuss coding decisions during code reviews. It will give you a safer and less confrontational way to understand and/or challenge some of your peers bad habits.