For those who are passionate about their work, some of them they put their person in their code. As someone else pointed out in a comment in this thread, it is about acceptance that none of us is perfect, we don't/can't write perfect code and that is totally ok as long as you did what you could (both in terms of the output and the effort to improve the quality of the output). Unfortunately this is largely conditioned by upbringing so easier said than done. But awareness of this itself can be a helping factor in coping with criticism.

But really thats what "you are not your code" means.

As much effort and ego you put in it, it will still suck in some way.

This is like the fundamental attribution error but applied to the self.

You wrote some bad code. You are not a bad code writer.

Well it is not unlike criticising an artist's paintings. The things you make are a mirror of who you are because you use your life experiences, knowledge, and preferences to make them. By criticizing what you make, they are also criticizing you by proxy.

Now sure it depends on the type of criticism in question. Finding a bug or other practical problems obviously isn't, but talking shit about a way something is arbitrarily set up that the author thought was really neat would absolutely be.

This line of thinking also reminds me of how every time some actor or director or whatever is implicated in some scandal, their work is also tainted forever instead of being taken at face value for what it is. Can we separate the artist from their art? Is it even possible? I doubt it.

The problem is that it's just unprofessional.

Code is made to be efficient in a compagny, it's not "personal" or here to make you have feelings. So if you can't discuss efficiency because you'll hurt people it's just bad. If you do art, you create art with respect to your own sensibility emotions so yeah be weary of criticizing someone's art.

You had better believe that when artists get a commission, the patron gets a say in how the work looks. When you are in a band or ensemble with other people, they also get a say in how "your" part of the music sounds. This is the same for code. Code you create with and for other people isn't really your creation in that way: all of it is a collaborative effort.

I don't think that really changes anything, just restricts the effective criticism to that specific part that you did. Though I suppose the more it's intertwined the less it matters. I don't think anyone really cares about that one function in the company codebase that's been rewritten 20 times by different people, and far more about that part of the game they coded themselves at a gamejam.

There's always external influence, but if you're involved you obviously added something and in most cases it can be scrutinized on its own merits.

To rephrase, criticism/review of your code doesn't reflect a value judgment of you as an individual any more than an artist's patron asking for more blue-ish tones reflects a value judgment of the artist. The patron doesn't think that you have any moral faults because they want more blue, they just want more blue. The same goes with criticisms of code.

I once worked with an absolutely horrendous programmer named "Sam" who enjoyed the smell of his own farts so much that he loved to be "artistically creative" with "elegant variation" of variable names and naming conventions (instead of boringly predictable like I prefer), and he always put his own name or possessive prefixes like "sams_" and "my_" in variable and function and file names (not to mention hard wiring the path of his home directory into code), just like a territorially possessive dog pissing on all the trees and fire hydrants he could find, and all the code he wrote sucked.

That made it extremely hard to separate the "artist" from their "work", and not to criticize the person as well as the code. But at least it was easy to tell at a glance which code needed to be tossed out and rewritten.

Elegant variation:

https://en.wikipedia.org/wiki/Elegant_variation

>Elegant variation is a writer's substitution of "one word for another for the sake of variety". The term was introduced in 1906 by H. W. Fowler and F. G. Fowler in The King's English. In their meaning of the term, they focus particularly on instances when the word being avoided is a noun or its pronoun. Pronouns are themselves variations intended to avoid awkward repetition, and variations are so often necessary, that they should be used only when needed. The Fowlers recommend that "variations should take place only when there is some awkwardness, such as ambiguity or noticeable monotony, in the word avoided".

you should make it a post of its own ><

Could "Sam" even pull that stuff anymore with PR review processes? I would just comment on every variable name in the PR to "remove sams" or "make clearer".

https://twitter.com/secondmentions is a collection of instances of said "elegant variations".

There's also this non intuitive fact that the critics you'll hear about are usually judgment free, at review time. Whereas you'll be judged harshly on your committed code and will probably never hear about it. We could summarize it with something like "hard critics prevents hard judgments".