[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.