What makes a great software developer?  Simple, anyone who has the ability to create and maintain quality software in a team environment are in high demand in today's technology-driven economy.  The number one challenge facing developers working in a  team environment is reading and understanding software written by another developer.  Java.Net has identified 5 habits that can be used by developers to make them more efficient at producing and maintaining quality software:

In my last blog entry, I talked about how I got Subversion to use Bugzilla accounts and passwords to authenticate users. At the bottom of that entry, I briefly mentioned that I use an “access file” to limit which Bugzilla users are actually authorized to access the Subversion repository.

Now I want to set up a nice web interface to the repository to quickly and easily track changes to the code. This is especially nice for people with “read-only” access so that they don’t have to install a full subversion client.

The tool I settled on for doing this is WebSVN (http://websvn.tigris.org/) which is a web repository viewer specifically designed for Subversion.

The tools that do one thing, and do it really well, are usually the tools that stand the test of time.  CVS definitely fits the description of doing one thing and doing it very well.  It is one of the best, if not the best, source control system available and is utilized by millions of developers.  However, CVS by itself does not provide any reporting capabilities or quick views into high level statistics about your source code tree.  Your source code is your most important asset and being able to view statistics, high level data, and commit logs is very important to having a well rounded picture of what’s going on with your code.  And this isn’t just for developers; Project Managers and Technical Leads should especially have a deep interest in monitoring code activity.  This is because many non-system "human" processes and procedures are put into place in order to control source check-ins and at times, even lock down the source through code freezes.  Without an easy to use, high level report about source code activity, how in the world will Project Managers or Technical Leads know developers are following defined processes? The answer - they won’t.

Sometimes you may find your team continually doing something that you wish they wouldn't do.  For example, you may find them continually hardcoding references to their c: drive in code, when the code eventually needs to run on a Linux box, but they never work on anything but Windows. 

When cases like this arise, it's almost obscenely easy to write a custom PMD rule to do code reviews for you to look for and flag these problems.  PMD (pmd.sourceforge.net) is a tool for doing static code analysis and producing XML output files which can be transformed into useful outputs (such as HTML reports) for later perusal.  Plug-ins for most major IDEs are also available.