If I thought the junior was not up to the task I assigned them, I would have had them consult with a senior developer during the task.

I'm literally talking about the case where a senior developer decides that this task was not implemented to their personal standards AND makes it a "teaching moment" that means it doesn't get delivered this sprint.

Saying "this can't ship without significant rework" is something that needs to get escalated, not ground out in a code review.

I'm an engineering manager with a coding background 12 years coding, 3 years managing, and "assigned as task" throws a red flag for me. I believe we should be (a) understanding what preferences and skills each engineers have (b) have a conversation on how they can best make impact using these (always comprises, sometimes a project just needs to be done and they're the only one free, but by that not being the norm, they don't mind), and (c) setting a goal for them to achieve (rather than a "task"). E.g. expose an internal REST endpoint providing these parameters with this latency and scale by two weeks, and letting them determine the tasks needed to get there. (obv this goal should be set together as well, not dictated).

> E.g. expose an internal REST endpoint providing these parameters with this latency and scale by two weeks, and letting them determine the tasks needed to get there.

But that is a task

Are you hiring? Asking for a friend...

This absolutely does happen and is a problem. Funny seeing so many replies mischaracterizing what you're saying.

The pile on is interesting. Apparently I’m a terrible, non-technical, micromanager who believes I own my staff and working for me would be a horror show. All because I’ve said some senior engineers go to far in code reviews.