This is helpful for sure, but it's also very useful to work on having a thick enough skin to take insulting feedback in a positive fashion. After all, the only way someone can offend you is if you let them.
You've offered a compliment, then suggestion, then a platitude, while telling someone that being rude is acceptable if it's technically correct and seemingly disagreeing with the previous poster.
It's sound advice, to have thick skin, but you've just shown how easy it is to give corrective feedback in a tactful way. Still good advice to not let people offend you though.
I'm a junior dev, I have a ton to learn and I don't for a moment think I know more than our senior dev. But working with this guy, and trying to learn from him, is a nightmare.
When I ask "why should I do this rather than that?", I either get a muddy explanation, or none at all.
Worse still is inconsistency. Just recently I was working on a project, went through several reviews without comment on the approach, was told "almost done just fix these tests". After waiting a week for review of those last tweaks, the review was "this is fundamentally flawed and shouldn't be done this way at all."
Now I'm not saying that's wrong, but it would have been better to hear that three weeks ago. Nor is the explanation of _why_ it's flawed the slightest bit clear.
Further, the new approach does _not_ support the business need motivating these changes in the first place. I am figuring out how to support that need within the directed approach, but it is harder than the first design would have been. Again, that doesn't mean I was right -- sometimes there are choices where you put the ugly stuff. These changes are pretty deep in our architecture, and so touch a lot of code. If being clean there means that some top-level stuff is more complicated, that is probably the right trade-off. But it would be nice to have a "sorry, I didn't think this through soon enough." And no, I am not the idiot I'm made out to be because I didn't, as a junior dev, immediately and fully understand how all the pieces should fit together.
Nor is this a two-way street. I've had moments where I've pointed out what seems like problems, been told I'm wrong, or ignored . . . and then find that the issue is quietly fixed a few days later. We do some stuff that is just flat wrong because that's how he likes it.
I'm not the only one, the others with more experience than I have similar problems.
I'm learning. The guy has good instincts, so his critiques usually lead in the right direction, so I roll with it and figure out the principles for myself. But it is absolutely zero fun working with this guy. I've become averse to submitting code for review, because I never know when the process will take 180 and stuff that was fine becomes crap. And while I think I'm getting better, I have to figure out how to build confidence in those skills, because I'm not going to get it from this feedback loop. Probably that will be working on my own projects, taking what I'm learning and using that to make them better. And at some point I'll move on.
Tough feedback, even insulting feedback, is ok with me. I'll work with it. But if you're going to be tough, then you have to be fair, you have to be clear, and you have to be right.
I usually ask more senior people why they say that, and keep asking why until I get it. If this process seems to be going on too long, I ask if there's a book or reference I should be reading to understand the subject better. Honestly, most senior people will be very pleased that you care enough to find out why, including following up with external resources.
If a senior person won't explain something if you ask politely, usually either they don't understand it themselves, or they are simply not very good at explaining things. Not all senior people are good teachers. It sounds like your team lead is one of the latter.
The problem here, and you'll encounter it with clients and seniors throughout your career, is that your senior/boss doesn't have enough time, or thinks they don't have enough time, to supervise your work correctly and thus comes in at the last minute and drops hidden requirements/fundamental changes on you. It's very common.
If you want to avoid this, you're going to have to make it your job to point out potential flaws and hurdles in your work as you come across them, to ask only for essential and broad-strokes guidance up front, and to find/fix smaller issues yourself as you go along without bothering the higher ups. Your senior probably genuinely wasn't aware of the deeper issues with your work because they just didn't have time to do anything but scan your code and hope for the best, because their senior is hassling them about a,b,c, which are far more important.
Now that was flawed on their part, and they're doing their job wrong, but you can help them fix that process, if you want to, and it is a good skill to learn. You absolutely should not be avoiding code review, you should be guiding that process in a direction that is in everyone's interest. The world of work is not remotely fair, clear or right - it is very rarely even one of those, but you can make it better yourself by managing upwards and making your requirements and concerns clear at a very early stage.
In my opinion the dichotomy of tough but fair/nice but inaccurate feedback is a false one. Most feedback is rushed, muddled, partly correct, partly irrelevant, partly insightful and still useful if you know how to mine it.
