One thing I learned is that having larger building blocks helps, as in relatively self-contained sections of code that fit together. Try to keep code chunks self-contained and with limited functionality.
Another thing I sometimes use is formal proofs, which can go pretty fast if you're practiced with them. Of course, these only work on simple things; if you've got complex code, a formal proof will be a lot more complex than the code, and you don't gain anything. It's not that code I've proved correct actually is, but that the remaining mistakes are typically big dumb ones that show up well with even limited testing.
Test-driven development is good. With luck, you'll find out about stupid mistakes immediately. I like to find mine when the logic is still fresh in my mind.
Other people can help find mistakes in code. Sometimes just explaining the code will bring out mistaken assumptions you hadn't thought of before. Heck, I had a friend who'd talk about bugs in his code with a large cardboard cutout of Captain Kirk (from the original Star Trek).
And, of course, remember that you're not alone in this. There are very few programs of any size that will go through a thorough examination that doesn't find bugs.