This is really great advice, thank you. "reviewing someone else's code is a not just a technical task, it's also a human one" So true.
We've been putting more emphasis on PRs and it's a bit tough as my team has a broad range of skill level and things that are obvious for some are not so obvious for others. I struggle to always be patient and when I see other reviewers being impatient I cringe a bit. If you have any advice with how to deal with that I am all ears.
That's a great question and we can approach it in many ways.
One and let's say ordinary approach would be that when you find hard to be patient, just think about most probably you also started as a junior with lot less knowledge than you have now. Maybe you also made those silly mistakes. Maybe not, maybe you already had an extensive experience by the time you started to work.
In that case, you can still think about this from a practical point of view. In what kind of a team would you like to work? Where the differences in skill levels don't decrease? Or you'd prefer to see those juniors grow into more senior roles.
From many of my former team members, I received a lot of coaching after reviewing my PRs. Usually, they didn't just write to do this and that, but they also shared why. If not, I went there and asked and they took their time. Without team I would do much more mistakes than I do - I still do a lot, I know.
All this is nice to say. But maybe you already did the coaching, you write great reviews, etc, but the guy doesn't change, just doesn't care, doesn't want to improve. It might happen.
As a last resort, you can still think about it in a pragmatic way. Do you have control on the employment of that guy? Maybe not. Do you want your code base to deteriorate? I guess not, that's what I feel from your comment. So just try to be patient and ask all those changes for not better than selfish reason. You want to keep your own environment, your own code base sane, whatever it takes.
If seniors' comments are not even considered, it is tough. Then you have to involve management I think.
Hopefully, you don't have to think about these last ideas.
By the way, you might want to consider not just educating by pull requests/code reviews, but through other channels too. In our department, we have regular coding dojos and soon we'll have other knowledge sharing sessions, about design, debugging, some specific libraries, etc. Hopefully, it will work out well.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.