1. Unit Testing
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!
Read more: XP on Unit Tests and Test-Driven Development
2. Code Review
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!
Read more: Code Review on the blogs of IBM and Jeff Atwood.
3. Pair Programming
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.
Read more: XP about Pair Programming, Martin Fowler on Pair Programming Misconceptions, WikiHow on Pair Programming
4. Keep it Simple
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
5. Design Patterns
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...
Read more: A classic design patterns book, A beginner's guide to design patterns on net.tutsplus.com
(Bonus) 6. Version Control with Git
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!
Read more: A completely free online book on Learning version control with Git and the First Aid Kit, a series of short videos on how to undo mistakes in Git.
Top comments (1)
Pair Programming and Code Review most often work only in a setting with juniors in the office. It will not work with pros in remote scenarios. They consider it a waste of time. Much more important is to have all code in shared repos where people are getting tasked to work on other's code. When this person will need excess time to understand the code, the two have to sort it out. Not before.