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.
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.
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.
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.
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".
I once worked with an absolutely horrendous programmer named "Sam" who enjoyed the smell of his own farts so much that he he always smurfed his own name or possessive prefixes like "sams_" and "my_" in variable and function and file and form field and database column names.
And he loved to get "artistically creative" with "elegant variation" of variable names and naming conventions,
permuting and mutating them at every level, and making up cute unique abbreviations by randomly dropping characters to save a few keystrokes of typing, then spicing it up with whimsical nonsense like "aardvark" and "pancake", instead of boringly predictable consistent correctly spelled descriptive big-endian names like I prefer. (He claimed that made it easy to grep the code.)
He would even alternate between CamelCase and lowerCamelCase and snake_case and Snake_That_Ate_A_Camel_Case and UPPER_CASE and runtogetherlowercase in the same fucking variable name, occasionally throwing in the random "sam_" and "_SAM" prefixes and suffixes for good measure!
He also liked hard wiring the path of his home directory into code, of course. He was 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 "arteest" 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.
Please don't be a Sam! There are some people who do deserved to be criticized as much as their code.
Elegant Variation (which is a terrible idea despite its fancy sounding name):
>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".
Big-Endian Naming Molds, Code Smells, Smurfing:
Felienne Hermans: How patterns in variable names can make code easier to read
DonHopkins on May 22, 2022 | parent | context | favorite | on: Felienne Hermans: How patterns in variable names c...
I like to use "big-endian" naming molds (love that term!) to define sets of names that when you alphabetize them place related variables next to each other. (i.e. in a completion menu or browser.)
For example, left_foo and right_foo are little-endian, since the least significant word comes first, so they'll be a long distance away from each other in an alphabetized list.
But foo_left and foo_right are big-endian, since foo is more significant than left or right. So they will appear one after the other in an alphabetized list.
Common suffix words are _x _y _z or _min _max, or _left _right _top _bottom, of even singletons like _enabled _loaded _error etc.
But when you combine multiple dimensions together in names, you need to think of which dimensions are more significant, based on how the variables are used, so use foo_x_min foo_x_max, if the positions are important, or foo_min_x foo_min_y, if the ranges are more important.
Sometimes it's hard to decide or ambiguous, so just try to be predictable and the same as all the other code. Think of which variables should appear closest to each other in an alphabetical list.
And avoid middle-endian or random-endian (or sentence-grammar-order-endian) like the plague. A variable name should probably not be a grammatically correct sentence.
Another really annoying linguistic naming smell is "smurfing," where all of class Smurf's instance variables have smurf_ prefixes. Or where all the classes, methods, or instance variables have an "xyz_" prefix where "xyz" is the name of the project or library. Arrgh!!!
SnowHill9902 on May 22, 2022 | prev [–]
Agreed. When dealing with real values, it’s favorable to explicit the units: weight_lb, length_cm.
DonHopkins on May 22, 2022 | parent | next [–]
Yes, explicit unit suffixes are good smurfs!
Also: eschew Bill and Ted's Excellent Postfix "_not", which inverts the meaning of the variable name. That's a most totally bogus code smell, dude.
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".
Also people who criticize people make a mistake kind of.
Always criticize the code, not the person.