I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.

Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything except simplest tasks.

Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it.

Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.

I feel like the problems you're describing are more workplace specific and not specific to the method of CR itself. For example,

> They started humble and ended afraid to do anything except simplest tasks.

It's the job of the team leads to create an environment where people (especially new people) shouldn't be afraid to try something out and learn from it. I've had plenty of CRs which went for some huge number of iterations when I first started, generally this was solved by spending some time thinking about designs on my own and then having a meeting with senior devs to discuss pros/cons and any suggestions before writing any code.

> Also, they got only and exclusively negative feedback.

This sounds really shitty, and this seems like a problem with the people on the team. I always try to put at least one positive thing in a CR after lots of criticism, and if there isn't that much criticism even better!

All in all it sounds like with or without CR, the team you're describing probably wouldn't be a pleasant place to work.

I agree with you, through I am pretty confident the seniors were well meaning. Insecure in more then one way, but still well meaning people with no intention to cause anything bad.

It is not that CR is has no place in the process. It is that it should not be primary tool for teaching, mentoring and leading. Nor talked about that way. Every forum and blog posts talks about CR as teaching tool and every discussion about juniors puts a lot of emphasis on CR and none on other tools. A lot of people think and act that way.

Yeah, it was a long time ago (2000-2003) but I still clearly remember implementing everything twice as a Junior Developer - first my way, then their way.

On the other hand it's possible for this to lead to senior developers who can't or won't leave their comfort zones entrenching designs and patterns that degrade the efficiency of the organization.

What you said is basically a tautology. "This method of mentoring won't work if you have bad mentors".

The person you're describing shouldn't be mentoring. The problem isn't the methodology, but their personality being poorly suited to the task at hand.

This industry frequently conflates effective producers of lines of code, with an ability to function in a senior role. If you look at other lines of work, seniority often implies things beyond "does the basic job quickly".

1.) Depending on the team, code review is either done by everyone non-junior or by the people most responsible for code base and expected to know most about it. It is last approve/reject step before admitting code.

So yes, this person will do code review. And code review has more functions then mentoring.

2.) Mentoring starts on task selection. Latest when junior start working on it - with senior occasionally checking the junior out while the task is in progress. Code reviewer might be someone completely else who might have noticed that junior is working on code only after it is done.

Sane mentoring should not start when junior finished the work.

If the reviewers are giving crappy code reviews, what makes you think they would be better at mentorship?

I it is different task. And you could assign it to different person.

Also, there is level of knowledge to be acquired about teaching and working with people. A culture that does not conflate code review with teaching nor talk about it as a primary means of how to deal with less experienced developers have better chance to develop that knowledge.

As in, admitting that those are different tasks is first step.