[watwut]

That is how I mean it too. For me it means not caring, as I said.

I have also found that accepting all criticism from other developers makes me the submissive one. They are not always correct, pushing back when they are not matters a lot. Otherwise you get more and more absurd complaints.

[tuyiown]

Maybe by seeing it that way: imagine you are emotionally invested, «caring», but the only thing that change is the way you interact with others, directly, or through the code you push.

Examples

• I don’t like this code style , I’ll post mine -> I’ll replicate the code style, maybe I’m missing something, and if not I’ll discuss it and propose my pref on next review

• reviewer suggested a change that would introduce an error, or something smelly -> treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation.

Your general antidote against bad effects of ego is to convert the emotion into a genuine effort to demonstrate your point. It’s hard, and failure to explain properly backfire, but it’s probably visible in your work too, so it’s great reality check to measure where your ego or humility should be

[watwut]

> reviewer suggested a change that would introduce an error, or something smelly - treat it as welcomed feedback, make sure to perfectly understand the seemingly subtle difference in approaches, and with a thorough explanation

I used to do that. The team dynamic went wrong every time. I ended up being the one people picked on the most, complaining about things they had no issue other people to do. And half the time it was not genuine code quality anything. It was asserting dominance or thinking I like it. The team dynamic is a thing. And all of this "be thankful" may be good advice for very aggressive people. I am not, for someone like me it is very bad advice.

When I was younger I read and followed advice like this. It was literally opposite of what I needed. Fact is, people react to what you do.

The thing that helped me was starting to push back on these systematically. Even when I feel bad about pushing bad. Or if it feels rude. And it really helped.

-----

If it is subtle difference in approach, then my way is as good as yours. If you want to change team approach, open it on meeting, get freaking consensus from all. Don't sneak it in my code reviews without any prior discussion. And do it for everyone, not just for the most accommodating person on team (which I am no longer and intend to never become again).

[tuyiown]

Ok, I didn't meant to introducing unsolicited advice, more like illustration to make sure that leaving ego didn't meant anything about caring or not, but mostly _how_ you do express your carefulness, especially converting into a constructive loop.

That being said, your default mode of conversion on this whole thread is confrontational, that facilitate self-cornering a lot, especially that leaving no open end in the conversation, forcing uneasiness. It's one burden to make sure the conversation goes well when one speaks.

I don't know you or your team, maybe nothing in this can help you, or maybe you are in a dysfunctional team, or even the fit is not good, but accepting things in a forever silence, without discussions, might really lead you into bad places. Leave some space in your mind for improvement, even if you're not ready right now, no reasons give up forever.

[watwut]

Two of my comments were purely expressing how I feel. Third one was tldr of my past experiences. Only the part under lines seems confronting, which is not that much and hardly a whole thread. I am really unsure about what corner I am supposed to lock myself in with these.

Also, it was repeated experience that has nothing to do with my current team. I am not in my first team and learned those lessons in the past ones.

And really, not every code review comment will improve you. Acknowledging that significant amount of them are pure preferences or even someone being wrong is not refusal to improve. And yet another category of them are half baked ideas. Just that, people give comments for variety of reasons and you have to manage them all.

[metters]

This is a good point and a perspective I neglected. Usually, when receiving feedback on my code I solve this by discussing the _why_ after receiving a _what_ as feedback.

When giving feedback, I try to do the same: Instead of just saying what is bad/wrong/smelly etc. and telling how to change the code I’ll also give the reasons why I think so.

The discussion afterwards should clarify the remark and I am open to the possibility that I am wrong. But you are right, at the moment I feel like currently I am giving up my approach/code too easily. This is partially because my colleagues are quite experienced and I’m very lucky to be able to learn from them.

Edit: Improved the punctuation.