[gchamonlive]

> I can learn more about you working with you for half an hour than I would ever learn by studying the code

That's the problem. I think everyone is too focused on technical prowess and forgetting something just as important which is written documentation and explanation.

Pair programming has the downside of selecting people with good interpersonal skills and will tell you nothing about quality of code delivered.

A good middle ground I believe is simple takehome tasks with focus on documentation that could be done in no more than two to four afternoons.

[BlargMcLarg]

>I think everyone is too focused on technical prowess

>and will tell you nothing about quality of code delivered.

These statements seem a little contradictory or I'm misunderstanding the context.

[gchamonlive]

Not being too focused on technical prowess doesn't mean being oblivious to code quality, so no I don't think they are contradictory.

[BlargMcLarg]

And you don't think that wording can easily be taken as "we focus too much on technical skills" while simultaneously saying "pair programming doesn't guarantee technical expertise"? Many people would think code quality is part technical prowess, at least.

If anything it at least showcases the importance of clear communication and how easily things can get lost in the details.

[gchamonlive]

There is also the principle of the benefit of the doubt where, in doubt, assume the writer is not a complete idiot. Goes a long way to filling these communication details without forcing the writer to write a philosophical thesis.