• Don't assume: Assumptions are the root of all evil. In many case studies on SW reliability and safety, failures can be traced back to an assumption done by a programmer in lieu of hard data.
• Know your tools: Not taking the time to learn to use your editor, CASE tool, debugger and other tools effectively is as stupid for a programmer as a chef that never sharpens his knives. "I have no time" the chef might say, but he wouldn't efficient in the long run.
• Learn a scripting language: Having good tools is essential, but nobody manufactures the excact tools you need. Learning a scripting language will enable you to generate code, sort through big amounts of data, extract important information from trace logs etc. All this can be done in programming languages too, but it takes time.
• Don't confuse the end with the means: You might love C++ dearly; it doesn't meen that it's the right tool for every job. Neither is Visual Basic. The same applies to other tools: Don't use a relational database if a stack of index cards will do the job.
• Never stop learning: Enough said.

That's all for this Thursday afternoon.

[Hmm, a journal function. What does it do? Klickety-klick...]

One small thing that's been bugging me; why can't people put a seperator between their signature and the message body? Or at least put the .sig in italics or something? Sometimes the signature and the message are hard to tell apart, especially since many people actually have a message in their .sig.