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.
