Writing better code whether as a team or individually involves three concepts: Harnessing Paradigms, Incorporating Communication and Thorough Testing.
I have heard of people say they work with companies that are exclusively a Java shop or .NET shop, preferring only to use certain languages and adhering to certain paradigms. Strictly using one language or paradigm over another because of tradition does not bode well for better coding. We should let the problem we are trying to solve dictate the tool we use. A carpenter that only uses a hammer will not be effective on jobs that require a screw driver. As a result, their capacity to expand is severely limited.
Communication between all stake holders is key, including conversations with yourself. We should keep these communication channels open to ensure expectations are being managed properly. Over-promising and under-delivering is not good. The same is true of the opposite. It is a waste of valuable resources, namely time and money.
Yes we should test the functionality of the application and unit test the code wherever possible. In addition, we should test the user experience from the intended audience’s perspective. All of these are absolutely valid, however, I propose we also test our level of satisfaction after completing each task. We should ask questions that can gage if we are still satisfied doing this type of work. This will help make our journey a little easier and ensure our future coding is indeed better.