The master replied, “Would you rather be a good programmer who writes bad programs, or a bad programmer who writes good programs?”

The student left enlightened.

I find that back end programs are in particular need of detailed logs.

Webapps are easier to debug because the request stack is usually smaller, after all, it will usually complete in under 2 seconds.

Most of my work is triggered by cron while I slumber, so if there is an issue I would like to read the log, rather than read the code to determine what happened in the small hours of the day.

Even more important when I need to debug somebody else’s program. If I can read the logs to determine what went wrong without reading the code, then I would say it’s written by a great programmer!

I also frequently add logging statements when looking for specific problems, but many of them I remove once the problem is solved. You can’t log everything, so you only want to keep the well-placed, generic logging statements that will also be useful in the future.

The type of logging I do for debugging is usually very specific to the problem I’m debugging and not suitable for staying in the code. Once I have the problem located and an appropriate test coded, I can then remove the logging. This allows me not to worry about the long-term usefulness of the log statements and merely debug the problem at hand.