I have a birthday coming up, so I decided to take a few days off from work next week. I need the break.

As an extension to the screed I wrote about COM, I considered writing in more detail about software components in general. But this topic really requires a book-length treatment, and is resistant to the usual "bad or good" comparisons. I disagree with most popular implementations of components (like COM), but the concept is sound enough.

Good programmers know when to use a given tool or approach; mediocre ones tend to blindly follow "the rules" regardless of their applicability to a given problem domain. I've met lots of shake-n-bake C++ coders who claim to know how to use the STL, but are then flummoxed when I demonstrate common algorithms like accumulate and reverse. Or they are completely in the dark about basic things like overloading operators.

This is why I always emphasize craft rather than art to my junior programmers. You want to be an artist? If you lack the basic craft, you'll be a crappy artist anyway. Learn the basics. Don't get fancy, and don't rely too much on wizard-generated code. If you don't understand what a given chunk of code does, don't fool with it until you do. Use (but don't abuse!) comments. Make sure you're solving a problem rather than a symptom.

It seems to me that the whole programming world worries too much about abstract methodology when we should be worried about simple, nuts-and-bolts stuff like code quality and readability.