2) If you can't accept changes to code you worked on (NOT "your code"), you're unlikely to improve.
I agree these are not absolutes. It might be that you understand the subtleties of some particular device / library / whatever much better than other people, and their changes to the code you wrote with those quirks in mind are bad because of their lack of depth. Talk to them, or better yet use meaningful names / comments in the code so that they understand why you wrote it that way.
sorry. i was not clear. i just meant to say that one need not agree or disagree with it in order to gain some value from it.
i mean, it's worth thinking about: "some people might get mad when i make a change to this unfamiliar, problematic, buggy code base. but how mad are they going to be? could my boss become angry with me? will i make any enemies? will i be a hero? will anyone even notice?"
mdpopescu|7 years ago
1) It's not your code, it belongs to the company.
2) If you can't accept changes to code you worked on (NOT "your code"), you're unlikely to improve.
I agree these are not absolutes. It might be that you understand the subtleties of some particular device / library / whatever much better than other people, and their changes to the code you wrote with those quirks in mind are bad because of their lack of depth. Talk to them, or better yet use meaningful names / comments in the code so that they understand why you wrote it that way.
HillaryBriss|7 years ago
i mean, it's worth thinking about: "some people might get mad when i make a change to this unfamiliar, problematic, buggy code base. but how mad are they going to be? could my boss become angry with me? will i make any enemies? will i be a hero? will anyone even notice?"