Ask HN: How do you not take criticism of your work personally?

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):

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".

Big-Endian Naming Molds, Code Smells, Smurfing:

Felienne Hermans: How patterns in variable names can make code easier to read

https://www.youtube.com/watch?v=z7w2lKG8zWM

>Name molds let you structure variable names to maximize the chance of different programmers guessing the same name.

https://news.ycombinator.com/item?id=31472523

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.

> What you have encountered is actually one of the necessary steps to really become "a senior developer". And congratulations, you have already passed the biggest part of that hurdle: becoming aware of the issue.

Fully agree. I tell people, if you cannot be humble about your code, you're going to deter yourself and others. It's okay to admit you may have "screwed up" (mistakes happen to everyone, even in production) the big thing to do is learn what was wrong, and if there's any steps you could take moving forward to avoid that mistake, the person commenting on your mistake probably made the same mistake, and worse it made it into production and now its ingrained in them.

Developers become adamant to prevent issues they or fellow team mates have ran into, even seasoned developers run into issues. Hell, even architects, and I've seen CTO's do the dumbest decision making.

What someone else thinks is their business - it's caused not by you but almost everything else that happened in the universe. Sometimes people just didn't eat breakfast, or someone beeped their horn at them on the way to work. Sometimes people are imbalanced and give inappropriate attention to the sign of fault. All of these things are not your responsibility.

What is your responsibility is if you chose to listen or not - you don't have to be involved or give someone else your attention if you don't want.

Then it sounds like you don't enjoy your job, in which case it is normal to feel bad when receiving negative feedback, and it also sounds like there are bigger issues.

For me it was always very simple: who is delivering the criticism. If it was someone for whom I had respect, both individually and technically, then I listened without taking it personally and discussed the why and the how. If it was someone I didn't respect, forget it. Their opinion didn't matter. Yes, sometimes that led to conflicts. For example, I once worked for a manager that I liked personally but didn't respect his management approach. He was a micromanager in the extreme, inserting himself into every discussion he encountered, looking over your shoulder when working, even insisting that every memo you wrote was reviewed and edited by him first. He'd red line your writing like a high school English teacher. Nonetheless, I followed this approach my entire working career and retired satisfied with the work I had done and with my ego and friendships intact. Nowadays I look back and laugh at some of the many characters encountered on the journey.