When developers are coding, most are doing what they think is their best. No one deliberately writes mediocre code, so reviewers need the tact and diplomacy of ambassadors. Few people have skin thick enough to absorb anything but the most constructive of criticism - and (that too) only when handled with kid gloves.
In my company I have not seen any evidence of code reviews (in the past three years) even though it's mentioned now and then in meetings as something that's supposed/expected to happen. I'm not sure how many companies enforce this as part of mandated quality control. In my experience, more time is taken defining and documenting a process than in any actual implementation.
Luckily, the Net is a great resource - we get to see/use code snippets posted for public consumption, forums such as ones on this site where people exchange their solutions to a problem - great articles with in-depth research (Jeff Moden always comes to mind here) - we get to see different perspectives and more importantly - learn why one solution is preferable over another.
If it were not for this, we would all have tunnel vision. I was lucky enough to briefly do some pair programming - it was an eye-opener in so many ways. I know it's not for everyone just as teleworking isn't, but if you pair up with the right person, it's invaluable. Jeff Atwood has a great blog about pair programming vs. code reviews - for anyone that cares to read it.
In the absence of any formal review process and even as an adoption of best practice, I have always learned to prefix my code with a meaningful comments block - whether it is to defend convoluted code or explain core logic - I find it helpful even when I myself revisit code after a long period of time - it helps me understand the reasoning at the time the code was written.
**ASCII stupid question, get a stupid ANSI !!!**