[hrayn3]

Your comments are very reminiscent of non-technical managers I've known - they often have a very shortsighted view of the value of code reviews, because they don't need to work on the code.

'It works - why don't we just merge it? Keep velocity high!'

A code review is exactly where it's worth spending time making sure: the code is maintainable, doesn't degrade the quality of the repo, and above all teaches the junior things they can use next time to do a better job faster.

Spending some time using a review as a teaching experience pays so many dividends later. People who don't touch the code don't understand that.

Of course, there's a level of 'good enough' a senior should be able to identify and approve. But the bar should be high.

[fzeroracer]

Your and some of the other comments I've read are very reminiscent of some of the worst senior developers I've worked with, because they treat code reviews as a way of molding the code base to their own personal expectations rather than improving it especially when a junior engineer finds fault in their code. They waste time using code reviews as a teaching exercise that gives bad habits to junior developers that need to be broken later.

[razemio]

Why? His comment was the perfect description of what a senior developer should do during a code review. Code reviews between a senior and junior are teaching exercises and always should be. It is critical and a fundamental step for juniors to be become more experienced. As already written by the comment you replied to, the right balance has to be found, but this is part of the job description if you call yourself a senior developer.