[bayindirh]

I think it's a spectrum. For example I like writing new code and designing new things, but I don't hate or dislike my or other people's old code.

That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.

It might not be good code, by our standards, but who knows how it was written. Was the author under stress, under time obligations, or happy, or something else?

Also, being able to approach somebody else's code and work with it is humbling and deeply educative for me. You get a (free) passage to a wisdom of a person or a group. That's priceless.

[evandale]

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.

Small piece of advice: it is much better to learn how to take criticism of your code as exactly that - it's criticism of your code. People will always be unkind when reviewing code. Even if it's the best code ever written someone will have a different opinion and express it in a seemingly unkind way. It's easy to be unkind in code reviews because it's _code_ being reviewed and NOT a person with feelings.

Like you said, a different human (the more junior version of you) wrote that code, not you. It's not a criticism of you no matter how much your brain tries to tell you it is. People will never stop saying "who the fuck wrote this shit!?" and you will hear that phrase until the end of time. It's still not personal when people yell that in frustration.

For example, I have learned that Eastern Europeans tend to be absolutely brutal in code reviews. Everything will be nitpicked and the most benign design decisions you've made will be questioned. They make you feel stupid and inadequate but that's your own feelings. It's more likely you're dealing with a direct and to-the-point perfectionist who can see the code beyond your PR and how your code fits in with the rest of the application. They're not the greatest at communicating this context and their comments seem like personal attacks without that context.

[bayindirh]

You're right, one needs to be able to take criticism, not about the code, but in everything, however being able to give criticism correctly is equally important.

This is not about style (kind or to the point, or in any style), but again about keeping in mind that you're talking with a human being.

You can say "This doesn't work (because of this), so do it this way", in thousand different intonations, and you can add the underlying message in anywhere on the spectrum of "this works better for our case" to "you're a triple distilled idiot".

This is not about being sensitive or having a skin, this is about mutual respect in a professional setting. When you do your to the point, brutal criticism, you cannot hurt the other party if you keep in mind that you are talking with a human being.

During my M.Sc. jury, one member called me a liar, and my professor had to intervene politely yet forcefully, and in my Ph.D. jury one member flat out insulted me, yet I defended myself politely yet forcefully.

They could have said the same thing, with the same words, in a much politer tone, but they preferred to attack me directly instead of attacking my work, so there's that.

I tend to give direct criticisms as well, yet I do my best to make sure that it's plain and simple I'm trying to guide and it's about the work, not about the person.

Because, I do not do anything to anyone which I don't want to experience myself.

[evandale]

Your handling of the PHD situation sounds perfect and it seems like we're in agreement.

I want to reiterate you will never be in a situation where everyone is respectful even if it's a professional setting. You also can't control what other people do so there's no point expecting people to give criticism respectfully or trying to teach people how to do so - you can't correct someone's behavior if they don't want to change it.

Every time I catch myself wanting to say "people should act like xyz" I stop myself and think "I will react a different way when someone acts like xyz" instead if I'm not happy with how the situation went. Especially if I've already expressed my feelings and someone has ignored them and still acts in a way I don't like.

[bayindirh]

Thanks. Yes, we're squarely on the same page.

I think I misrepresented myself. I don't expect anything from anyone, in any setting, or I don't intend to change anyone. Who am I to expect to change someone?

I just wanted to say that, I behave the way which I want to be treated. I ask myself, "what would I feel if that's done to me", and if I don't like the answer, I change myself, and try to better myself step by step.

Actually "The Four Agreements" by Don Miguel Ruiz sums up pretty well how I live this life. It's a surprisingly thin yet dense book. I recommend it wholeheartedly.

Looks like we try to do the same things with slightly different methodologies. My hat's off to you dear sage internet stranger.

Wish a peaceful future awaits you.

[lll-o-lll]

I agree so strongly with this. It’s all about the code! You need a tough skin in this game, and the ability to seperate emotion from the end goal “good code!”.

I love the Eastern European approach; blunt and to the point. The French are also good for this. We anglos are so sensitive, and so afraid of offending, that you end up with a silly inefficient dance. “Have you considered? Perhaps if we tried this approach…”. No! Give me “this won’t work, do it this way” every time!

[BossingAround]

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice.

Not only has it been written by a human, but one should also remember that they're missing the context in which the code was written. Was the author stressed about their latest children being born? Fearful of possible layoffs? Under time pressure? Tired?

I've definitely written code myself that came to bite me later, and I marveled at how badly written that was.

We're all human, which, among others, means that we're all inconsistent to a large degree.

[fragmede]

Also important is Chesterton's fence and the history lesson when touring existing code. What were the business requirements the first time around that were thrown out the window for version two, but there was no time for refactoring so version three has this known wart that version four tried to refactor but that wasn't complete until version five which had this new feature that needs another refactor.

[j45]

Brilliant summary and the parent comment.

Too many developers remain hyper committed to shiny object syndrome, or wanting to relearn lessons of the past as if they are the first to ever lay eyes on it.

No code is perfect, and lots can be learned even from a well intentioned approach gone wrong.

It’s far easier learning from other folks and their rattlesnake bites instead of insisting of recollecting that baggage yourself, first.

Greenfield is still useful, but too often it has to do with preference and interpretation or a lack of willingness to do so.

[HeyLaughingBoy]

The funny thing is when you get used to someone's coding style, you can tell if they were stressed or under time pressure or not.