So, for my first post here, I thought I'd try to garner some opinions. There's no wrong here.

I'm a senior developer, and a little over 6 months ago, I was asked to interview a woman - whom 3 of us agreed should be hired into the team. She was hired as a junior.

Fast forward 6 months, and she's working on small projects with lots of time investment from myself & others to start a Sprint. She then works for a full sprint having the usual standups etc, and has delivered a project within a single sprint.

My issue, is the code reviews.

I've always treated code reviews as "if it fits the requirements, it gets merged" and we don't have anything like style guides to worry about. If I can't work out quickly (based on the review content and the commit history) what a section of code is doing, I'll ask the author.

Unfortunately, code reviews with her are ALWAYS world war 3, everything is taken personally, and combative responses are the norm. Simple things like "did you consider X here, would have probably been a bit more efficient?" get a response of "no, and I'm not going to change it, this should have been discussed in requirements before the task was given to me." Consider here, I'm talking about things like static import use in Java, nothing complicated.

Yes, I still merge the code (because it obeys the functionality rule). But I can do without the arguments daily over the tiniest of things.

I could stop commenting, but that runs the risk of simply whitewashing her changes & allowing the defect rate to rise if I'm not paying attention.

I could take the hard line of "buck up or get another job" but I'd rather find a way to help her take on feedback healthier.

So, after that lengthy rant, what are your tips for reducing combative responses while helping juniors grow?