Here are a couple of more tips about things that either I use or that aggravate the heck out of me...

1. While it’s ok to write articles about things that have already been done (almost everything HAS been done in SQL Server), DO NOT PLAGARIZE! Do your own research, your own work, and your own writing. In those cases where you must make heavy reference to an existing article or other source, make sure you acknowledge those sources either as proper footnotes or as embedded text.

2. DO write an "Introduction" that talks a little about what the purpose of the article is and, maybe, what someone will learn by reading it. Every article should have a goal and it should be gently introduced in the "Introduction". That's why they call it an "Introduction".

3. While it's certainly OK to make a "pretty" article with pretty pictures and screen shots, make sure that any and all code is either in a code block that can be easily copied or included as a "resource" near the end of the article as an attachment. If you include the code as an attachment to the article, you really should let people know about it as a parenthetical comment in the Introduction.

4. When I first started writing, I made the mistake of using the site editor to do the writing with. Don't do that. Do the writing in a decent word processor with a spelling and grammar checker especially if your first language isn't English (actually, English speaking people seem to have a real problem with the language, as well ;-)). Transfer the text and graphics to the site editor only when you're done writing. If you make any changes, make sure you spell check them in the word processor you're using and make sure that you test any code changes.

5. Import all graphics into the word processing document to make sure that they can be imported and that they make sense according to the nearby text. I recommend that all graphics (unless just decorative) have a figure number so that you can easily refer to them in the body of your document.

6. There are very few articles on this site that don’t contain code. Code is what it’s all about and you really need to put your best foot forward. Properly written code can make up for a wealth of sins in the text. The code should be nicely formatted and shouldn’t contain super long lines. It should be properly indented. It should be appropriately commented with, perhaps, a small header explaining its purpose in life, as well. It should be consistent in format. For example, if it’s your style to capitalize all SQL Server keywords, then make sure they’re ALL capitalized. If it’s your style to make mixed case variables and column names, then make sure they’re ALL mixed case.

7. You should have test data available for your code examples. If the test data uses something available to everyone such as the “AdventureWorks” database that comes with SQL Server, then no problem. Otherwise, you’ll need to provide test/demo data and it should be in a “readily consumable” format which includes the CREATE TABLE statement and INSERT, SELECT/INTO, or INSERT/SELECT statements to create the data. For increased credibility especially in performance related articles, I strongly recommend you learn how to build large volumes of test data without using a While Loop or other forms of RBAR.

8. Do not ever claim any type of performance gain or efficiency in your code unless you prove it in the article with LOTS of test data and have tallied the results. Otherwise, people WILL eat you alive especially if you’re wrong.

9. This site supports all versions of SQL Server. If a particular version of SQL Server is required to support the code in your article, then identify what that version is as a courtesy to your readers.

10. Name your article after what the article talks about. While that may seem obvious, too many people try to get clever with article names making it difficult to find in the archives or with Google. For example, if your article is mostly about how to make hierarchical tree structures using Nested Sets, don't call it something like "Going Ape in the Bushes". That's a nice little splash but no one will ever find the article again. Instead, call it something like "Building the Nested Set Hierarchical Model". One of the best ways to name an article is to ask yourself, "What would my Google search be if I wanted to actually find this article."

11. Last but not least, any code you post DOES ACTUALLY HAVE TO WORK or people will think you’re an idiot. TEST, TEST, TEST!

Writing is a heck of a lot of fun and isn’t really difficult at all. Have fun at it. You don’t need to be a professional writer to write articles for SQLServerCentral.com. Just remember that your work is being published on the Internet with a possible viewing audience of millions one of whom may be your next boss ;-). Even though you may not be a professional writer and whether you write in a professional style or a “Developer-to-Developer” style, always put your best foot forward.