I used to go through the same experience once a week. I'd open up some code that I wrote a couple of months ago, I'd read a bit of it to understand what I was trying to do, and then I'd conclude that I'm a complete moron.
Based upon that crazy, kludgey mess I wrote just a few weeks back, I'd realize that, not only should I be barred from using a compiler from the rest of my life, but that I probably can't be trusted around shoelaces and sharp edges either. Code like that is why they sell malt liquor.
Okay, most of my code wasn't that bad. A great deal of it was fine, acceptable code. However, when I looked back on existing code, I'd always find this one little corner of disturbing weirdness that just shouldn't be allowed to live. At the time, I'm sure it made perfect sense, but looking later, I could only suspect that severe head trauma was involved.
Wouldn't it be great if we could catch ourselves each time we took a leap into Bizarro Code Land? Wouldn't we save ourselves a great deal of frustration if these code abominations never made it into the codebase to begin with? Wouldn't it be cool to look at old code and not have to stifle a sob?
The good news is that it's actually easy to spot these mistakes when you write them. The bad news is that you're not going to be able to spot them yourself. This, my friend, is why we all need code reviews.
Don't Be Afraid
Just the term "code review" gives some people the shakes.
It sounds like you have to present a detailed report (with footnotes! and a bibliography!) on every line in your application to a committee of pointy-haired bosses who are about to start flinging rotten fruit at you. That's not it at all, though.
We're all into people over process, right? A code review can be as simple as having someone watch over your shoulder for 45 minutes as you walk them through your work for the week. No committees! No lengthy reports! No rotten fruit! It's just you and someone else having a conversation about your code.
You may want something a little more formal if you're writing the firmware for the Space Shuttle, but simple and informal code reviews do wonders for the rest of us mortals.
Good Code Reviews
What's the difference between a good code review and a bad code review? In a bad code review, you leave feeling terrible about yourself. In a good code review, you leave feeling terrble about yourself, but you also have a list of things to refactor. Just kidding.
So what actually is a good code review? For me, it all comes down to a few practices that are easy and effective.
A good code review focuses on the code. Some people seem to think you need to bring in all manner of class and sequence diagrams for a code review. You don't, unless insanity by UML is your idea of a good time. Just fire up the editor and start looking at code.
A good code review results in agreement. There has to be give-and-take in a good review. If you're reviewing my code, you can't just declare, "This sucks, rewrite the whole thing!" Likewise, I can't just declare, "I hate you, you insufferable ass! This code is perfect!" A good review should produce a list of reasonable refactorings to make, and this should be a list that both the reviewer and the reviewee agree on.
A good code review is an intimate affair. 
That's not to say you should be doing code reviews in your underwear while listening to Barry White. By intimate, I simply mean it should be you and one or two reviewers. With a small group, you can go through the code quickly and easily, and the conversation doesn't spin out of control. Otherwise, it's Review by Committee, and the Committee might quickly go from, "Hmm, this is interesting," to "Why doesn't our framework do this," to "Let's rewrite everything in Erlang!"
That's not to say you should be doing code reviews in your underwear while listening to Barry White. By intimate, I simply mean it should be you and one or two reviewers. With a small group, you can go through the code quickly and easily, and the conversation doesn't spin out of control. Otherwise, it's Review by Committee, and the Committee might quickly go from, "Hmm, this is interesting," to "Why doesn't our framework do this," to "Let's rewrite everything in Erlang!"A good code review is limited in scope. You've had too much Nyquil if you think you can cover an entire system in a 45 minute review. Instead, focus on something that a person can reasonably understand in that time period, like one particular feature or a specific business process. It's better to go deep than shallow.
A good code review isn't a one off event. We want to do outstanding work and produce things that are so awesome that shiny medals and honorary keys to the city are in order, right? You can't do that consistently if your code is reviewed once every 6 months. Once you see how easy and interesting these simple code reviews are, weekly reviews with a teammate make perfect sense.
A good code review has a good reviewer. There's no point at all in doing a review if the reviewer doesn't know a string from Porky Pig's bowtie. Pick someone you respect; it should be someone who's qualified to suggest changes in naming, variable scope, object oriented design, database schema, etc. It should be someone who'll feel comfortable telling you, "What is this load of digital feces?" Don't pick the intern.
The Final Practice
A good code review occurs. If you aren't actively reviewing code, then stop reading this right now. Walk over to the person next to you. Ask them when they have an hour to look at some code. If they are in the bathroom, sit there until they come back. If they don't come back, knock on the bathroom door and ask if they need some Pepto Bismol. Then ask if they have an hour to look at some code.
If you're scared by code reviews, it's only because you're not doing them. Start today and help yourself build something great.
