Peter Marklund's Home

As programmers we have a tendency to take shortcuts that come back and bite us eventually. It is very popular to write overly complex system that seem sophisticated and make us feel smart and special. The irony is that a lot of times we think our code is so simple and obvious that it doesn't need automated tests. Here is a list of programming practices to consider:

• Failing silently / swallowing exceptions. Failing silently can make debugging a nightmare since the source of failure is not revealed. Don't do it.
• Not using version control. This shortcut is suprisingly common. Being able to roll back your code to an earlier version is a great debugging technique.
• Not writing commit comments. Let the commit comments serve as documentation. You may also want to keep a high level change log where your customer can review changes.
• Including several unrelated changes in one commit. This makes debugging and code review more difficult and makes it harder to see each change in isolation.
• Not commenting your code. Are you breaking conventions and being particularly clever? Explain what you are doing in a comment.
• Leaving commented out code or unused code lying around in your code tree. This makes the code more difficult to read and understand. Keep the code clean.
• Not following programming conventions. Every programming language and framework has certain conventions that you should follow. I've found this to be particularly important with Rails. Respect the decisions that the creator of Rails has made and stay on the golden and well documented path.
• Not writing automated tests. With the testing support in Rails testing is more worthwhile than ever. Once you have seen in practice how testing improves your design and keeps you from breaking current functionality you appreciate its value. Try writing your tests before you write the code.
• Choosing the complex and generic over the simple and specific. Avoid over engineering and being an architecture astronaut. Don't think too long term in your requirements.
• Having too little communication within the development team, and between the development team and the client. Err on the side of asking too many questions and ask questions regularly throughout the development cycle. Release early and often and collect end-user feedback. Keep track of what your fellow programmers are doing.

In summary then, keep your code clean, simple, conventional, and well tested and listen to your users. Those recommendations may sound obvious, in practice though they often contradict our instincts as programmers and require discipline and courage to stick to.