Documentation As Your Legacy

Based on hearsay, developers hate documentation…until they come across a project with no documentation!

As you leave your company, how do you want to be remembered? Let me put it this way, if the next programmer is a serial killer that has to review legacy code that you wrote, would you want him to know where you live? Once I thought following a zero comment policy as good because classes, methods, variables should be human readable and obvious, however, there will always be someone who complains about the lack of comments and that your documentation is overwhelming. So, comment sparingly, but when you comment, complement the existing code and comment specifically business reasons behind your code. It’s also useful to use tools in your IDE that automatically apply comments to properties and classes. This is important, but if you comment every object, please don’t leave the default auto-generated comments in there, as they are just as useless as no comments. Finally, you should always reference your code classes to the user-friendly documentation in some other system (such as Confluence). If you comment your code where appropriate and also provide documentation for all your code, then you will be appreciated long past your stay.


Excuses to Avoid When Working With A Team

Here are some of the most common excuses developers make when working with a team. Avoid them to be an effective programmer.

  • It works on my machine!” (It is functional and worked on my computer.)
  • It is not in the software spec.
  • It is not in my test plan.” Or “not enough time…to test everything
  • The (meta)data is incorrect
  • It worked yesterday.
  • There is something wrong with your data.
  • Is it deployed or is the server restarted?
  • I can’t reproduce the problem.
  • You have the wrong version.
  • There was no time to test it.
  • Somebody must have changed my code.
  • I am out of touch with that particular module for a very long time
  • It’s a hardware problem.
  • The computer has a virus

Remember, if it’s a problem, it’s usually an Id10T error, which means the problem lies between the computer and the chair.