I've noticed a few new SQL blogs spring up over the last month or so and someone asked me on Facebook this morning about linking etiquette so I thought I'd lay out a few quick thoughts I have on the subject – some "dos", mostly "don'ts" – as general advice for successfully blogging in the SQL community.
Don'ts
-
If you're starting a new blog, how are you going to get readers to follow what you write? By writing about something interesting to them. One mistake I see a lot of people making is starting a series that simply rehashes material that's been out there for ages. For example, do we need another series on how SQL Server data structures are put together? Do we need another series on choosing the right non-clustered indexes? And so on. Unless you're putting a different spin on the topic, or introducing new material, it's been done before. Blog about stuff you've discovered that other people *haven't* blogged about ten times before. I know I'm kind of breaking this rule with this post because I'm sure others have written similar posts before, but an advice post is different from a technical post, and this is my spin on it.
-
Steve Jones (blog|twitter) makes a good point in a comment below – paraphrase "if you're using your blog to show-off your professional skills, blogging about something that isn't new can be worth it." I'd still say that there should be a new twist to the material, throw in some anecdotes, and link to some prior art too.
-
-
Don't be scared to start blogging. You may not be the best writer, but "if you build it, they will come" – popular misquote from the movie Field of Dreams. It can take practice, but it's really satisfying to see people reading and commenting on your stuff.
-
Don't use four-letter words in your posts. Or racism or anything else that's guaranteed to put people off. I swear like a truck-driver, but I don't like reading it in blog posts. You need to be able to express yourself without swearing.
-
Don't plagiarize. Plagiarism means copying other people's work and passing it off as your own (through deliberate or accidental lack of attribution). It's also a violation of copyright – copying work without asking. You're not allowed to do this by law, and it's very, very bad manners. The SQL community at large is vehemently against plagiarism. If you want to quote a paragraph of material, copy a list, or re-use an image, ask the person first. Most likely they'll say yes (I always do if asked first).
-
Don't tweet about your blog post using the #sqlhelp hash tag. That's not what it's for and you'll annoy people.
-
Don't tweet about your blog post multiple times in quick succession, or at high frequency (e.g. hourly). You'll annoy people.
-
Don't copy chunks from Books Online or whitepapers. Reference them with a link.
-
If you're correcting some misinformation that you've seen on the Internet, don't link back directly to the post you're correcting. That makes it personal. Others may disagree on this, but I do it this way.
-
Don't be scared of doing short posts announcing something, or a really long post that goes into depth on a topic. For a long post, I like to put headings every so often and a summary at the bottom.
-
Don't get fixated on page view numbers. If you blog good stuff, you'll get a following. I track the numbers for the various SQLskills.com blogs through Google for a couple of reasons: various Microsoft programs (e.g. MVP and Regional Director) like to know what kind of community reach the blogs have, and I like to see what topics people are most interested in.
-
Don't post NDA information. If you're in doubt, ask first. There's no such thing as asking for forgiveness afterwards when it comes to NDA material.
Dos
-
Make it entertaining and let some of your personality shine through. People love to be entertained while they learn.
-
Use a spell-checker. I always take the blog posts and stick it in Word to check spelling and grammar – it found 4 spelling mistakes in this post. I crnge when I reed things that ara spelt wrongly. Beware of apostrophe usage especially. (Did you notice the typos in the middle sentence?)
-
Put in links to people and their posts. I like to do links like this: And Brent Ozar (blog|twitter) wrote a similar article about snow-blindness in cats here. That's actually a quote from the excellent movie Talladega Nights. People like to have their stuff linked to, and then you'll see people linking back to you.
-
Tweet about your blog post using the hash tags #sql and #sqlserver, and anything else that's *relevant*.
-
Split your prose up into digestible chunks. If I see a page-long paragraph, I move on. I like to use bullet points too (you may have noticed :-)
-
Use the same nomenclature for describing features, algorithms, internals as everyone else does.
-
Make sure what you're posting is accurate, and clearly explained.
-
If you use someone's name, make really, really sure you spell it correctly. I see Randall very often because people don't bother to check. I'm used to it, but it still rankles.
-
Same thing for company names. I see SQL skills, SQLSkills, SQL Skills. None of which are correct (it's SQLskills) – do the due diligence.
-
Use catchy, descriptive blog post titles. If people are skimming RSS feeds, you want your post to stand out.
-
Invite feedback through comments, and make sure you respond to comments when appropriate. If someone takes the time to ask you a question after they've read through your post, give them the courtesy of some of your time to respond. Then they'll continue to read your blog.
-
Remember that everything you post on your blog will be preserved for all time by Google and Bing. This means prospective employers, spouses/partners, children, parents can and will see what you're posting.
-
Check with your employer whether you need to put a disclaimer on your blog and whether you can make (even oblique) references to anything at your work.
-
Be careful if you're a consultant and you blog about something you did for a customer. Make sure they're not going to be annoyed with you.
These things work for me – I have a successful blog (you're reading it aren't you? :-) – and many others too.
The final "don't": don't take personal affront if you're doing one of my "don'ts" – think about whether you should change for the better.
And the final "do": do let your knowledge and passion for SQL Server shine through your blog posts! Enjoy yourself!
PS A lot of the tips in my long post Public Speaking: A Primer also apply to writing good blog posts too.
32 thoughts on “So you want to blog about SQL Server?”
For "Don’ts" I’ve always considered not posting on the weekend as a biggie, but now I’m re-thinking that. Less competition? Less eyeballs too, but worth considering.
I like the name (blog|twitter) citations. I’ve been just using the name for the hyperlink, but this reads so much better.
Good stuff!
A very nice post and it speaks to the heart of the matter for why I have not started blogging; too much good stuff.
I find there a very large pool of great SQL information already available from talented people who give to our community. When I have considered writing about a topic, I generally find it is very well served by our community in blogs, white-papers, and forums. Additionally, the list of topics I am able to blog about is bound by corporate and competitive guidelines which tend to remove all of the really fun topics.
There are the interesting topics like "When correct is a killer — Trade-offs in performance when your covering index has a fast-changing column versus including the column", but that topic steps into the competitive area for me.
All-in-all, I appreciate what you, Kimberly, and everyone else write about and use it all to enrich my hard-won knowledge and skills.
Nice post, and good advice.
I’ll disagree on the part about posting something new. If you are blogging for your career, to raise your brand and show off your skills, it becomes important to show that you know how to backup a database properly, restore a log, stripe a backup set, etc. I view a blog for most people as a career chronicle. It’s a nice resume extension.
For someone that wants to use it as a publishing platform, which is completely fine, then I think your advice is spot on.
One minor disagreement/exception on the ‘don’t link back when correcting bad info’ – when the bad info is in the official manuals. I recently wrote a blog post challenging some commonly given advice, and linked back to where that advice is stated in Books Online. Wouldn’t do that for a personal blog, but for the offical docs, sure.
So what is the correct SQL skills spelling? I’m guessing it’s uppercase "SQL", lowercase "skills" two words. But I see it differently in a couple places. (i.e. my RSS feed is called "SQLSkills Complete Team Blog")
"Use the same nomenclature for describing features, algorithms, internals as everyone else does."
That’s a really great point and is something I neglected to mention in my own "blogging tips" blog post. Common terminology is so so important and a pre-requisite to good communication. Thanks for highlighing that Paul.
@Steve Yes, you’re right. I’ve added an addendum to that point with your point.
@Robert Indeed, and choosing not to blog can be better than having a boring blog.
@Jeff Yes, I used to think that but now I just post whenever I feel like something should be posted about. RSS readers will always pick it up and I usually RT on Monday morning.
Good point Gail – I added a note in the post.
Good set of advice. I have a hard time waiting to post something after I have written it. I have not gotten in the habit of "banking" posts for the future like Steve Jones and Brent Ozar do, but I need to try.
I tend to like and respect blogs that are mostly technical, and ones that regularly have new content.
It’s SQLskills.
Awesome , this post will be a great advice for all the wannabe bloggers. Thanks much Paul.
An excellent resource: 10 Copyright Myths covers the types and circumstances where copying falls under Fair Use / Fair Dealings
http://www.templetons.com/brad/copymyths.html
He does update it, so keep it bookmarked.
[ D O N ‘ T ]
– Tell me how to use the product
– Tell me what conference you attended
– Tell me about a feature you think it cool
– Again, don’t tell me how to use the product!
Example of wrongness: "Here’s how you make child SSIS packages inherit variable values from their calling parent packages," with tedious screenshots.
[ D O ]
– Tell me why I should use one product facet/feature over another
– Teach me about process and methodology
– Refer me to a good book (note the "Don’t" above)
– Lead me to different problem solving approaches
– (I think it’s clear.)
– Learn me something new! Don’t just rehash what’s already out there, everywhere
Example of goodness: <am-ready>
I have a different view about choosing topics.
When I first started blogging, and when I talk to people who are just starting out, the biggest problem is usually "What do I write about?" It’s intimidating– there’s a lot of content out there. It’s very easy to think everything you know has already been covered and that the TiVo is looking kind of lonely.
I encourage new bloggers to write about whatever they are interested in, learning about, or passionate about, period. Regardless of whether there’s a lot of posts on the topic, I think the key is your final "Do": "Enjoy yourself!" I think the best blog posts are where people are actively thinking about something.
Here’s a question: "What is the benefit of a technical blog?"
Hopefully my blog has provided some benefit to other people, but it’s provided great benefits to me as the author. When writing a blog post on a topic, I always learn something new about it, and I tend to retain the information better. I’ve also come to see things differently and learned a lot from others’ comments on my posts, and I really value those. But I would say that incorporating the process of writing into learning all by itself is valuable, and that is a good deal of why I encourage people to start blogging.
Great comment Kendra. There are many many posts that deal with the same issues/topics, but depending on the audience they will enjoy a different author more than others and they will have their preferences, maybe one blog is written in a more friendly manner than another that is very formal, and maybe both explain the same topic but at the end, reader will choose one depending on their reading habits. Also, maybe the blogger read many blog posts about one topic and the author wants to make her own recompilation of material, in a way that is clear for her. But definitely, like Paul said: Enjoy it!
As a former truck driver: I used to swear like a DBA
As a DBA: Well, never mind.
Excellent set of suggestions. Especially on checking spelling on names. I screw that one up more than anything else and it’s not good.
Paul,
How do you define success? If it’s in terms of reach, or number of subscribers, trying to blog about things that haven’t been posted online before probably isn’t going to get you very far. One interesting thing to note is, according to Google reader statistics, http://blog.sqlauthority.com/ is the most subscribed to SQL Server blog with over 6,000 subscribers. Your blog, while much more interesting to me personally, has just under 900 subscribers. Brent Ozar has just under 1,700 if you add his feeds together.
Your blog has very deep technical content that is interesting to a smaller audience. So, it all depends on how you measure success.
-Rob
Great advice Paul.
I was wondering how people create the "(blog|twitter)" tags? Is there a simple way to do this, or does everybody just do it by attaching the different links the "blog" and "twitter" words?
Is it ok to just tag anybody like this?
Thanks! There’s no simple way to do it – it’s just like you say. I don’t see why not – tagging is cool.
In "The final "don’t": don’t take personnel affront if you’re…" you might want to replace personnel with personal.
Good article – Thank you.
Curiously, no advice about checking your work for accuracy before posting. Lots of bloggers make bad guesses, then post it as if it’s fact. Do: post your whole method. What did you observe? What was your hypothesis? What did you try to prove or disprove it?
Got it – thanks!
Good point Mike – I’ll add something in. Thanks!
"Especially on checking spelling on names. I screw that one up more than anything else and it’s not good."
I ALWAYS copy paste names, never will I type it manually. That way I will never get it wrong.
One thing I can’t stand in a tech blog is when the author says, "Create a insert-object-here" or "Turn on such-and-such" making the assumption the reader knows how to do this. Please at least link to some step-by-step instructions on how to do ‘x’. Many times I’ll have to halt reading the post to google that issue and figure it out before I can finish the original topic. It’s easier to stomach if the author links to another page on how to do ‘x’ than if I have to try and google it myself, with the chance I actually can’t find a good step-by-step.
On that note, if you, the author, can’t find a good page to link for a step-by-step assume your readers might not either, and so please put a short bullet list on how to implement ‘x’ before moving to the next steps.
Great point Jonathan – that’s why I always include a T-SQL script that shows what I’m doing. I must admit, I read the comment and thought you were commenting on my seekable WHERE clause post from the weekend and thought – but I DID do that! :-)
Nope it wasn’t you, Paul. =D
Great Points !!!This Definetly gave my blogging aspiration a quick boost
Very Nicely explained article. Thanks a lot for sharing!
Thank you for such a great post. I did not notice ‘ara’ spelling mistake till you mentioned in next sentence.
Hey Paul – I enjoy blogging and I know I shouldn’t look at numbers (as you say above) with that being said mine sucks! Any ideas to stimulate further growth? The issue I am finding is that new stuff doesn’t get views because its too new (nobody can relate), old stuff, well its been written before a thousand times by more qualified/intelligent people
Arun