The non-existing(?) practice of surveying an individual's methods of trade, and fixing them through inquisitive, critical-but-helpful approach.
An example of this review can be demonstrated in the context of software development: a reviewer sits with a developer, much like in a CodeReview (not going into whether code reviews are effective...) and reviews the way this individual programmer works; it can revolve around everything - from his selection of shortcuts on the desktop, aliases in her .bashrc, to where they chose to compile, how they create test-suites (whether they create test-suits...), etc. This can all be done without actually looking at code, and these practices can influence the developer's work a great deal.

This can even be extremely important, for example: developer X is generating the release version of the company's product. It takes a lot of time, and when bugs crop up at the client's site, the support people fail to compile the code when they suspect they found the bug. Turns out that X has used a mix of old libraries with new code, and the exact mix is not documented.
This can happen (it happened, dammit!), especially in start-ups where there isn't always a release engineer. However - this is common sense, which can be noticed or overlooked by anyone. This is why a second eye should be useful.

Of course, I'm making this up as I go along. But maybe this practice exists, by another name? This subject looks like it has a strong relation to ProcessSmells, but is only vaguely related to subjects such as ProcessPatterns.

I dislike code reviews as much as the next developer, so is there a better way to do it? Is someone doing this, or some other method of insuring individuals work as efficiently as they can, fixing each individual's problems and strengthening their good points?

----
CategoryMethodology