I've been writing code since I was 16 years old (on a GEAC mainframe programmed in BASIC). I've worked on development teams of one (me!) and over 1,000 developers, and everything in between. I've written some bad code and some great code (my humble opinion!). And in all that time I came up with a few simple rules for writing Great Software. They're all straight-forward:
Use Source Control. If you don't use source control (even a simple system like CVS or RVS) you can't have more than one programmer effectively working on the code. Simple as that. Without version control you can't roll back errors. You can't be sure that you're not overwriting someone else's partially complete code. And you can't be sure who's working on what. And, most importantly, you never lose code when you're using a source code control system properly!
Do a Daily Build (from Source Control). If you are part of a group of more than one developer, do a daily build as soon as it's possible to start them. This ensures that checked-in code (source control!) compiles properly and one person didn't just break the build due to a local file dependency or other silly reason. On larger teams, I like to trigger builds at lunch time and after work. Smaller teams can get away with daily builds. It's a really simple way to find major mistakes: if the build fails, fix it first! That way, everyone has an unbroken set of code.
Do a One-Step Build. If you can't run a single script to do a complete build, it's too complex. A single-step to build the exes or installers should be all that's required. If it isn't a single step, you've got a potential source of errors.
Fix Bugs Before Writing New Code. If something breaks, fix it right away and not "later". Later never comes. Fixing bugs takes time, but it's a lot better than fixing it after the customer has complained!
Track Bugs. Use a bug tracking system. That way there's a record. Each bug ticket should include reproduction steps, expected behavior, actual behavior, and a fix status (as well as who is fixing or fixed it and who verified the fix). Even a spreadsheet is better than scraps of paper, but today's integrated systems have really good bug tracking software.
Follow the Specifications. Of course, you DO have a spec, right? Software churn occurs most often when there's no spec (call it a functional specification, or a design document, it tells you what the software does and how it should do it). Specs take time to write, but nowhere near as much time as rewriting code that doesn't do what it is supposed to! Average time to write a design document is one week. Average time to code software is many times that. Write it wrong, redo, you've wasted more than a week!
These are all simple and obvious, but you'd be surprised how many companies don't follow these simple rules. You should...