A Really Best Good Practice

It's been a few years since I've written a lot of code. Certainly I've written individual scripts to perform particular hacks, and I've cobbled together little systems here and there over the past few years, but not writing code day in and day out, I had forgotten the value of something very important.
Last week, I was re-introduced to manual code review - and on paper at that. I used to have a co-worker who always insisted on printing out code, complete with line numbers. He'd have a highlighter and a pencil handy. I never really understood what the big deal was. But last week, being re-introduced to it, I saw value in it like I had never seen.
There's a great deal of value in getting your code away from the computer to analyze it. When you review it on the computer, you have the ability to fix it right away, rather than see pieces in context to determine better architectural changes that you might not have otherwise observed. Also, getting the code on paper gives you the opportunity to really focus on a section of code, without being distracted by other sections, or (heaven forbid) email, IM, the newsreader, etc.
And there's even greater value in getting your code in front of your teammates. Even if you're the sharpest person on your team (I am not), you can learn from the less sharp on your team, and you're doing a benefit to those on your team who aren't familiar with particular algorithms or techniques.
So if you don't do it, begin doing team code reviews. On paper. With a highlighter and a pencil. And if you can't do it on the entire codebase, do it particularly on the most critical sections of code (which might not be the most interesting parts). You might actually find some things a static analysis or a pen test might not find. And you just might learn some things that help you write better code the first time.