Simple suggestions for 'team' programming

Most programmers think that they are unique, that the way they program is the best, and they program only for themselves. This selfish attitude, however, does more bad than good. Working as a team has more advantages, less individual work, better cooperation to achieve deadlines, just to name a few, so why don't we (developers) learn how to cooperate?
Here I put four suggestions, which are so obvious to me, but I don't know why most programmers don't wish to follow:

1. Use and apply design patterns; they help better communication between the team as the provide for a common language; not to mention all the other advantages they provide, like extensible code, program to an interface etc.;
   
2. Don't hesitate to write javadoc and comments; they save another developer that looks at your methods and classes much time to know what it does than having to go through the code to realise what an uncommented method does;
3. Write test cases; they are mainly for documentation; they show another developer what is the input to a method and what to expect as an output than having to guess each time, especially when there is no javadoc;
4. Use this *bloody* CVS/SVN of yours correctly; add a comment each time you do a modification letting others know what you did and why. E.g. another guy just erased (or moved to another eclipse project) some classes in the team I work, and he never writes anything in CVS, letting me in nowhere of knowing why he did that and he 's too busy to ask.
   

If you have never heard of design patterns, then here are some references you may find useful:

• Gamma E., Helm R., Johnson R., Vlissides J. (1995), Design Patterns – Elements of reusable components, Addison-Wesley.
• Vlissides J. (1998), Pattern Hatching, Addison-Wesley.
  
• Freeman, E. & Freeman, E. (2004), Head First Design Patterns, O’ Reilly.
  
• Eckel, B. (2003), Thinking in Patterns with Java, http://mindview.net/Books/TIPatterns/
  
• JavaCamp, http://javacamp.org/designPattern/index.html
  
• Wikipedia, http://en.wikipedia.org/wiki/Design_Patterns

Write javadoc comments even to package or private methods explaining the algorithm that you use, any reference to a web site or book, and of course reference back to the use case or requirement that forced you to write this method. In eclipse it is also very easy to produce the html API by clicking on the project in package explorer and then to menu Project --> Generate Javadoc.

Creating junit test cases is also very easy with eclipse, just right click on the class you wish to test and choose New --> JUnit Test Case. Eclipse will ask you of the methods that you wish to test and will create the skeleton for you.

Next time you write a piece of code, think that you don't write it for yourself, but also for others who might review it or continue from where you left or need to modify it. Stop thinking selfishly; it doesn't help.

Heinz Kabutz also gave an interview on becoming a Better Programmer in SUN's website.