You know these situations, when somebody else touches your code and your programmer ego comes up. For example somebody fixes a bug in your code, or worse ;-), refactors your code without consulting you before.
What are your strategies to keep your ego under control?
The question should probably be closed as it's the same situation as with everything else in the world and therefore not really programming related.
Don't be a control freak, remember that the patience is a virtue and that you would be much better off with good cooperative atmosphere on the project than with your code untouched.
P.S. Also discourage people from 'owning' parts of the project code as it is a bad practice :)
P.P.S. If the change in your code is good you could express the gratitude towards the changer. If it is not that's what the source control is for
If you have such an ego, you deserve to be hurted by words. (long integers I prefer)
When somebody else touches my code, I see he appreciates my effort and wants to help. If he ends up helping wrong there's nothing bad in it because I evaluate and improve my code anyway.
In the other hand, I'm not working for a company and programming is a target of passion for me. There's little of outside interest on modifying code I've written alone.
Everyone on the project should own the code. Have everyone rotate through various modules. Having one guy being the "expert" in a particular area is a real problem when he leaves.
Treat your code with ruthless contempt in the first place. Use Test Driven Development. Be proud of the tests you write, but understand that requirements change and therefore so does tests. The implementation is irrelevant as long as the tests pass.
Decouple your emotion like any other dependancy.
It's not my code. Nothing is my code unless I'm actively working on it. This is the company's code unless I'm actively working on it.
As well as any bug that is assigned to me is MY bug. It's really important to distance yourself from your code. No emotion should be linked to your code.
Don't forget that you are always working for your client. That is how I personally keep my ego in check. Call it denial if you want ;)
We're pretty careful to avoid individual "ownership" of both code and design documents, so once it's in the source code repository, it's the team's code. If someone alters code I wrote, and it's better than before, I have an opportunity to learn something. If someone alters code I wrote and it's worse than before, it will get reverted during code review.
This is a business and I write code to make money, not earn bonus points.
I've had to "turn over the reins" on code before. The easiest way was to move on to something else (newer technology). Fortunately, my boss made sure I wasn't held responsible for the code, once I'd "let go"
When things work well, all I say is "it's what the customer wanted"
I have no problem with it if they are right. But if they are wrong.
Once I had a coworker, that had to use a common class. The class has a float parameter but he did not like floats so he changed it into an integer breaking the build for all other applications.
If they do that kind of thing with my code, I have to kill them.
That's a question of code ownership. As long as you feel you own some piece of code it will be difficult to accept changes/fixes/critic/etc from other programmers.
Try to think in a more pragmatic way - it doesn't matter who wrote the code in the first place or who fixed a bug. Your only concern should be to enhance the quality of the code you are working on.
If your employer notices that you are working on the things that really matter (generating more revenue) you may be able to gain additional benefits - that's a win-win situation for you and your employer.
If it was truly your code, nobody else would have access to it. It is, in reality, your employers code which you are allowed to modify, along with other people your employer deems suitable.
Maybe I'm getting old, but I don't care too much about this sort of stuff anymore. If you can convince me that your fix is better AND that the benefits outweigh the cost (this is important), go right ahead and change 'my' code.
I show humility... and I can't do it better than let someone else review the code I've written. You never know when you find something interesting with another set of eyes. It may be painful at first, but you only get better if you let someone have a look at your code.
Use the Ten Commandments of Egoless Programming. Suggest (Make?) your team read them. Take ten deep breaths. Go for a walk in the park.
Once it is in version control it no longer belongs to me. It is removed from my responsibility. That being said I have checked in bugs and they were caught by someone else. I congratulated them on finding them and helped fix them since I am currently most familiar with it. Of course the opposite happens as well. We are a team of developers, no one owns code.
As I constantly change "other people's" code, I may not be annoyed if someone changes code that I've written. As long as my teammate adheres to common coding conventions (and maybe the implicit coding conventions that the particular code has) and does not break anything, it will be fine with me. I try to write my code as comprehensible as possible, so people won't break things inadvertently, just by not understanding why the code is like this.
Make your code so incredibly complex that nobody else dares touch it.
I use Interfaces on my Interfaces man!
Ego? I'm far more critical of my own work than anyone else ever will be. Not that I would suggest low self-esteem as a solution to anyone's problems - but you did ask.
Instead of thinking about it like that, just think of your code as open source. Anyone who touches it [hopefully] improves something. Crowdsourcing!
Having sex.
Suddenly, programming doesn't seem to be that important.
After finishing my code, I make it a point to give some high level overview to our team. So when testing team lists the bugs in code, any developer is asked to look and fix it. It's not the developer's property anymore. If a person doesn't gets it, he can ask for the help of the guy who developed the code. Thats it.
I think this is good. Because the developer who developed this code can jump onto other tasks, instead of working on the same stuff again and again. But we also make sure, he too fixes some of the bugs. When people fix the bugs in their own code, that helps them in writing better code and helps them avoid the mistakes next time.
And another advantage is you can go on your vacations and people will not bother you while they are fixing the bugs in your code.