Yes, a developer should not test his own stuff!
- Group code review turns on circuits in your brain that see errors you ignored before. I call it the audience effect.
- The dialectic tension between tester and developer is also an important resource. You love it, but he loves to find fault.
You deserve pretty code, so indent, tab align, slip in white space to keep things neat. You get paid back in better review, fewer errors and faster fixes. Every time you use a new line or each item, you help track changes in line oriented CM tools like SCCS and diff.
Log like you expect a midnight call when you are on vacation. After years of debugging with bad logging, I am now a fastidious logger and error checker. From first trial run to last is very short, usually, because my code does not go far off the track but I get a nice message and exit. Frame runs in the same log with header and trailer lines and blank lines. Put exact time stamps on all events. It's frustrating to be fixing errors in the wrong log. Put date-time-elements in file names, especially the log. For daemons that run many days, use syslog or start a new log every day. You can have a standard logging routine that saves the integer time() of tomorrow so I can check time() and close the log when necessary, with an old log trailer and the new log with a header.