That's the DESIRE for what the junior learned. But is that what they actually learned? One could just as easily (or more easily) decide instead that this is the way business is done. It's literally all they've ever seen.
Responding politely could also teach the junior that it's ok to act like an asshole, because he'll get a polite response no matter what.
I suppose the ideal response would have been a polite correction, followed by a polite rebuke regarding the junior's tone and behavior, but I can't fault someone for responding to fire with fire on occasion.
A polite response does not have to be a meek response. You can be blunt, you can point out all the problems, while still being polite.
That also has the advantage of being 100% clear.
"You just told hundreds of people my code is poor. You attacked me, and my professional reputation, and you did it inaccurately. This gives me little reason to respect you or want to help you. Asking without copying the world and without assuming you were flawless would have done a lot to help your case. Because I AM professional and you are new to the profession, I'll hold back on the reflex to point out to every one of these hundreds of peers that influence your career how rude, presumptive, and WRONG you were. Instead, I'm pointing out in private that you are wrong and not behaving in a way someone looking to succeed is behaving. This tolerance is not something you should expect from me again, and you should be grateful to be getting it now because your behavior does NOT call for cooperation. If you do this again, the next person will likely not show this patience and understanding.
Do you understand that you made the error in your code? Do you understand how your behavior invites people to think poorly of you? Do you understand how to change both your code and behavior for the future? "
This has the senior developer takes on more work instead of a sense of vindication. However, this is much more likely to get a positive result in the long term - there's no mystery hope that someone that clearly missed out on social repercussions will suddenly understand them when attacked.
Being a senior developer is not about winning battles, it's about learning to win without battles, and even more importantly, it's about TEACHING that.
I've gotta say, if I was a third party to the exchange that involved your suggested message I would think the senior developer was a pompous and condescending ass. In the UK we (or at least I) wouldn't consider what you wrote to be a polite response.
Funnily enough, my last team worked with a software supplier from the UK, and I’m 99.99% sure the above text was copy-pasted from an email reply to one of my overzealous team members. We thought it was over the top, but chalked it down to British culture
There is also a difference between teaching and grandstanding; the reality of the situation is that there is no single correct response for this kind of situations: the junior maybe was zealous, maybe he was trying to shame the senior, maybe he just copied in CC the wrong mailing list.
Obviously the original answer was not appropriate in every situation, but also likely it was appropriate in some.
So what they've learned is, if someone makes an incorrect assumption, sends a nasty email, and CCs the entire department, I get to respond by sending an email back pointing out their error and CCing an even larger audience.
I don't think that's necessarily a bad thing to learn, even for the junior...
There's no way to know in advance what someone will learn from an experience. You also don't know what they learn 'now', and what they might reevaluate and relearn years from now about that same situation. Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond.
Couple folks I'm working with right now, and I had thought a couple of times "well, this wasn't a great scenario, but at least they'll learn ABC from it". One did, one didn't, and keeps making the same moves (I hesitate to say 'mistakes', but in my view they are).
> There's no way to know in advance what someone will learn from an experience.
Correct. You can, however, improve the odds. Being explicit about what you want them to learn as opposed to expecting a certain degree of interpretation cannot hurt your odds, though it can't guarantee them.
> Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond.
In this context, what else was the point of the response? I was comparing to the STFU tell-off of the above post and the defense of it that they would learn from the experience.
