Why? Every programmer has experienced something like this: you change a bit of code in one corner, and in a (seemingly) unrelated corner, something breaks! The bitter truth is: both new and changed code will inevitably contain bugs. Use automated tests that help you keep old code stable.
Keep in mind: You can also go one step further and write tests before your actual code. This can give you a whole new perspective on how to approach problems!
Why? Code that is ever only seen by a single programmer in your team is dangerous code: if that person gets sick or leaves your team, no one knows how this piece of your software really works. Additionally, no matter how great and experienced that developer is: it might be that he overlooked something, implementing only the second best solution.
These problems can easily be avoided by always having team members approve each other's code. It's both a quality control as well as a means to create collective ownership of your project's code.
Keep in mind: If pair programming (see below) is already an integral part of your workflow, you might not need additional code reviews!
Why? Pair programming is an ideal tool to share knowledge in a team. Having a junior and a senior developer sitting side-by-side is the best way for the junior to learn. And since teaching is a great way to sharpen your own skills, even the senior can benefit.
Keep in mind: Make sure that each person gets in front of the keyboard on a rotating basis. It shouldn't become a "I teach, you listen" event.
Why? Planning for the unlikely makes code unnecessarily complex. Don't try to foresee your project's requirements in two years from now - too many things can (and will) change! You would waste time on an overly complex solution for a problem that proves to be different than you thought.
Keep in mind: Keeping it simple shouldn't be confused with "quick and dirty". You still have to work thoroughly and carefully!
Read more: KISS on apache.org
Why? At its core, most programming problems belong to one of only a few general categories. These general problems have already been solved thousands of times - and are well-documented in a couple of "design patterns". Step back from the problem in front of you. And you'll be able to apply a proven best practice instead of reinventing the wheel.
Keep in mind: Applying design patterns shouldn't become a religion. Sometimes, all that's really necessary are a few lines of simple code...
Why? Git and version control are often underestimated: being proficient with Git has the power to make you a better programmer - and help you build a better code base!
Keep in mind: Git is about more than just "commit, push, pull". Take its many "undo" features and you'll quickly understand how helpful it can be!