Mechanical posts are ones that are either auto-generated, or manually input with no real additional work put into them - an example of this in action is if you use Delicious to auto post to your blog each time you add a bookmark. This technique has it's place, but it's easy for it to become annoying...great you added a bookmark, but why?

Lately I've been soliciting input on my blog, trying to see beyond my own tunnel vision (see Blog Review - Yours & Mine) and while the follow up on that is still to come, some early feedback from my friend Steve Jones was that he thought I had too many mechanical posts and was maybe too erratic in my topics. I'm limiting the discussion today to the 'mechanical' posts. The majority of the ones he considers the offenders relate to articles that I've posted on SQLServerCentral.com, you can see the work I've done over the past year by using my tag cloud filter.

Some samples:

Renaming Databases was just published on SSC, another in my lastest effort to expose some of the hidden complexities in seemingly routine operations. Definitely read the discussion thread attached to the article as there were several very good additional tips suggested.

This was actually posted about a week ago, fell behind a little during travelling. Building a Security Philosophy was written to get people to think about they approach security. Do you give the proverbial Junior DBA only partial access? Do you believe in table access? Do you use the built in roles? I have opinions on the topic, but it's not clear that there are always right answers, and definitely some that are situational. Many of us have the philosophy that we acquired at the first job, or from the first manager or peer - at some point it's worth revisiting to decide if we still agree with those principles held for so long! 

Moving Tempdb isn't a common operation, and mercifully a simple one if it comes to that. As in much of the stuff I write about I wanted to put down a nice detailed answer to a pretty simple question. Think you know how it works? What happens to the original tempdb mdf/ldf if you move tempdb? Do they move? Get deleted? Read the article:-) 

Rebuilding Stats was published yesterday on SSC, some nice comments posted to it as well. The main point of the article was that if you're rebuilding indexes with the default options you're automatically getting stats update on those columns as well.

My overall goal is to post anything I do professionally that isn't my day job here, though I expect and know that many clients and potential clients will look to see what I write about and am interested in. When it comes to true technical content related to SQL I prefer to post on SSC for a number of reasons; I get paid for my work (the entrepreneural spirit!), it gets a little more exposure than my blog does, I really enjoy the discussions that follow content being posted on SSC (and that seem to rarely be as deep or as interesting on blogs), and I'm biased in favor of supporting the community that I helped build (and in turn helped me grow).

So the easy option is to just post the technical content here, forego the reasons above. Not thrilled with that. Or just omit adding it to my blog, not great either. The alternative - as Steve tries to demo in The Agile Cult, is to try to add value to the smaller post here than points to some other site with the main content. His matching editorial won't go up until tomorrow, so for now I'm grabbing his word count from today (Mon) as 530, and his blog (excluding the intro is about 320). My last article posted on SSC was about 630 words. Do I want to write an additional 25-50% over and above each article I post to make it non-mechanical? Or am I missing a step by not baking a little more of the why I did write this into the article (though it's often as simple as someone asked me to explain something, nothing more complicated)?

As I look at my examples above they are short. Probably not much shorter than the standard blurb that gets shown in the SSC newsletter, but short. One place not discussed that I think I've probably not done a good job is when I've posted a few times on tools I use. I've listed the tool and lightly discussed, but haven't posted a full review with screenshots, etc. I'm torn there, I think in some cases a little more work would really help someone understand why I like a piece of software, in other cases my comments will either interest you enough to read the link, or not!

My goal has been to tell those of you who follow along with me that I've done something external to the blog, and lightly encourage you to read that as well, or not. While clearly a two or three sentence post wouldn't work for his daily editorial, I'm still not convinced that brevity is a flaw. Don't want to miss an opportunity to learn, but also have to work to make sure I separate style comments from substance comments.  I'm going to wait to watch Steve do a few of his prequel posts to see how they come out, maybe if I see it done it'll be easier to implement. Either way, I expect to learn from the exercise. And while it may look like I'm really really down in the weeds looking at details, I think that level of introspection is required at times if you want to master something, and clearly I haven't mastered blogging nor settled on a solid place to analyze my results from.