[unfug]

That's an interesting idea. Did the original author of the work walk the junior team member through what was going on, or did they just point them at it and have them check through the work on their own?

It seems like that could be helpful. My main concern is that a lot of junior devs need some specific direction (as opposed to just telling them to go read some code) so we might need to setup some specific expectations for the results of the code review (maybe have them help write documentation?).

[brudgers]

In the situation I described, review [of drawings] was part of the QA process, and going through the QA process was a requirement before anything was "shipped" [sent to the plant for fabrication]. So all that happened was that the normal roles for junior and senior staff were reversed for a small portion of the normal work-flow [i.e. a senior staff member did a lot of QA and a little production and a junior staff member did a lot of production and a little QA].

If review was just something that was done sometimes [and those sometimes being either slack periods or seen as part of correcting a situation in need of remediation] then it would not have made sense. It was only due to the fact that the junior staff member's sign-off was required "to ship," that the process was meaningful.

One of the side-effects was that some of my wild and crazy ideas that arose from not knowing any better were identified as seriously off target. Another side effect was that some of those wild and crazy ideas got adopted as standard methods because they worked and improved workflow.

If it isn't clear, I don't think code review assignments as punishment or busy work are worth pursuing.