SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

My Approach to Writing for SQLServerCentral

By David Poole,

Over the years I've been submitting articles to SQLServerCentral I have watched the site grow to over 1 million registered users.

The success of any organisation is always dependent on new talent coming in and old talent nurturing it. With that in mind I thought I would describe how I go about writing an article for SQLServerCentral.

I don't claim to be a great writer, but having written nearly 40 articles for SQLServerCentral over the years I can claim some experience.

I hope the article below will help at least some of you to write your first article.

Writing is about preparation

So you have a fantastic idea for an article, leap in to the writing process, start reading around only to find that someone has already written a piece of unsurpassed brilliance on your chosen subject!

This should teach you that writing requires a fair amount of research and preparation.

I read an article by David Eddings (fantasy author who wrote "The Belgariad") describing the process of writing.

The example he gave was the background he had to create in order to generate the character of a leader of a tribe of nomadic horse herders. He pointed out that you can't simply jump in and write about such a character you have to ask yourself a number of questions in order to generate a believable character

  • Ok he's a horseman what's his terrain going to be like?
  • What is the weather like in such an area?
  • How does his tribe find food, trade with outsiders and support itself?
  • What characteristics will his people have as a result?

None of this background work would be included in the eventual book but it isn't wasted as it is used build a more rounded and convincing character. In David Edding's case he recouped his costs by selling exactly the same story three times (The Belgariad, Belgarath the Sorcerer and Polgara The Sorceress).

Technical articles are a different genre but exactly the same principles apply

  • OK it's a write up of a SQL experiment
  • What drove you to carry out the experiment?
  • How did you carry out the experiment; what was your methodology?
  • What were the results and what conclusion did you reach?

In the case of my SQLServerCentral articles I write between 60% and 70% more than I eventually submit. In the case of my review of "The Data Warehousing Toolkit" I wrote 23 pages of notes using a writing pad and an HB pencil.

I should also recommend "On Writing" by Stephen King. Even if you are not a fan of Stephen King's work he is phenomenally successful and there is much to be learnt from his techniques.

Preparation notes

So what goes into my notes? I would categorise my notes in the following way.

  • References to materials such as interesting hyperlinks, useful diagrams
  • Outline paragraph headings, perhaps with a summary of what I intend to do under those headings.
  • Blocks of actual article content
  • Paragraphs that link blocks of content together. These probably won't survive to the final draft as they are mechanism to indicate that two content blocks could probably be rewritten in a more appropriate way as a single block.
  • Details and suggestions of tests to be carried out
  • Potential order in which I think the sections should be placed.

How long should it take to write an article?

Q. How long is a piece of string?
A. Twice the length of the end to the middle

In other words it depends. I think the quickest has taken 3 days; the longest took 2 months.

I find the majority of my time on an article is spent in the preparation and editing phases. The ideas and writing are relatively quick.

You should spend enough time to be able to generate an article of quality but not so much that you never want to write anything ever again!

Some thoughts on article ideas

Thomas Edison observed that success was 10% inspiration and 90% perspiration so statistically coming up with the article idea should be the easy part.

So where do I get my ideas? The author Terry Pratchett responded to a similar question by saying "a big warehouse called Ideas R Us".

I would categorise my source of ideas as follows

  • Things on which I have mentored other people
  • Things on which I have worked
  • Books I have read
  • Subjects I have researched
  • Bolt from the blue, divine inspiration, eating cheese too late at night etc.

By categorising the intended article I have a mental picture of what will be involved in writing the article. Not quite a template but certainly with a leaning towards a pattern. Going back to our horseman analogy each article type has a "terrain" that I use to determine its likely structure. The category also gives me an indicator of the likely strengths and weaknesses both in terms of how much work will be needed and also the difficulty in writing the piece.

Things on which I have mentored other people

I believe that things on which I have mentored other people are by far the easiest articles to write.

  • It is real world experience.
  • Mentoring another person, or better still a group of people will expose you to many different perspectives on a single subject. I find writing from such a source produces a much more rounded article due to those perspectives.

Things on which I have worked on

There is much of a muchness about business computing so writing from your experience is likely to be relevant to someone else.

There are two pitfalls in writing about your work

  • Confidentiality
  • Mono-dimensional perspective

You must not breach any confidentiality clauses in your contract of employment. If there is any doubt in your mind as to whether your article contains material that could be construed as confidential then assume that it will be construed as such. This is very important in these troubled times.

I have always been completely open with all my employers about writing for SQLServerCentral.

By mono-dimensional I mean you had a problem, you found a solution, perhaps pressures of time on your project prevented you from investigating a range of solutions. You can obviously fill in the blanks when you write your article or you can wait until the constructive criticism comes in.

Books I have read

I have only written one such article on Ralph Kimball's Data Warehousing Toolkit and have to say it was the article I worked hardest on. For a start you have to have read the book thoroughly at least once. Unless the book is unremittingly awful you will probably have to read it more than once which obviously takes time.

Another downside is that it is quite hard to write about a book without regurgitating the book or simply listing the table of contents.

That said there are advantages to writing such an article.

  • A solution either works or it doesn't. An opinion is your own and as Voltaire said " I do not agree with what you have to say, but I'll defend to the death your right to say it".
  • In effect you are writing metadata. It is not the subject matter of the book but an article about the subject matter of the book

Subjects I have researched

The plus side are as follows

  • If you have researched properly then you will have gained multiple perspectives of your subject
  • It offers the most freedom of any article

The down sides are

  • Research can be laborious and time consuming.
  • If you are researching to learn a subject as opposed to polishing your knowledge then you can completely miss the point.

If you miss the point then the forums will be full of constructive criticism. This is a positive thing so read it carefully.

Eating cheese too late at night

Life is like an analogy was definitely a late night Stilton article. I wasn't sure if would be appropriate but Steve ran it and many of you enjoyed reading it just as much as I enjoyed writing it.

If you can write these deliberately and successfully then you have missed your calling. Phil Factor is particularly good at these sorts of articles with his "Two stops short of Dagenham" being my particular favourite.

When to edit your writing

Obviously if you are writing 60% to 70% more than you need you are going to have to edit your work to get rid at least 60% to 70%.

My personal opinion is that there are two times when you should avoid editing your work

Don't edit while you write

Writing is a creative and positive activity and you should sup from the creative juices while they flow.

Editing is a negative activity where you prune, cull and pollard your work.

If you try and combine the two at once then the good in either one tends to cancel the other out.

Don't edit on the same day that you wrote it.

If you are basking in post-creative rosy euphoria then you won't be in a sufficiently ruthless frame of mind to edit your work.

Sleep on it and see if your opinion of your work decreases when viewed in the cold light of a new day. You may have a different opinion of what works and what doesn't. You may find that on reflection parts of your article simply don't work and need either culling or rewriting.

If you need to rewrite part of the article, then again, don't try and edit it on the same day.

I may be somewhat hypocritical in saying that an article is finished when there is no more that can be left out without detracting from the article as a whole.

My tips for improving your writing

The first draft

I've already said that you shouldn't edit as you write. For the first draft write down everything that you think will be relevant.

When I say write sometimes I mean just that. Pencil, paper, post-it notes, flow-charts, drawings.

You can scribble notes to yourself in the margins, memorandum to do further research, speak to people etc. Don't constrain yourself in any way.

Remember you can always cut a long plank shorter but you can't cut a short plank longer.

Experiment with alternative ways of phrasing your article

This is really part of the editorial process. Sometimes the sentence is in the right place and has the correct intent but it just doesn't sound right. Don't be scared to experiment with different phraseology. It can sometimes reveal a way to simplify your article.

A good thesaurus is a Godsend.

Print out your article and read it carefully

I find it far easier to read an article if I have it on a sheet of paper. It also makes it far easier to annotate and edit.

Writing style

I used to work for a documentation company and was introduced to a process known as information mapping. This is a trademarked process that has influenced my writing style.

It is a way of thinking about what you are writing and structuring it in a form that is very easily digested. It is hard to put into words and your best bet is to follow the hyperlink. The nearest I can come to describing it is to say that the technique is about the following

  • Extracting the facts that you are trying to present
  • Presenting those facts in a way that draws the eye to those facts

This is why my writing tends to have a lot of bullet points and tables in it.

Write to provoke a constructive response

I am indebted to Erik Bitemo who posted a note on the forum in response to my article "How to break replication". His tip has saved my colleagues and me days of work and his tip continues to be a lifesaver.

His response was precisely the sort I should most like to provoke.

One strategy I use to try and provoke such a response is to include any test methodologies as well as any results when I am researching a subject. I do this for the following reasons.

  • I'm increasing my chance of getting constructive criticism. The type of person who provides a critique of a method is not necessarily the same person as will provide a critique of a result.
  • Both my method and results are transparent and subject to peer review. The responses will define the rigour of my methods and validity of results.
  • There will almost certainly be responses that outline alternative methods of experimentation. These can be added to your arsenal of DBA tricks.

The response you should be aiming for is constructive criticism, or at least criticism from which you can learn something.

Read as much as possible

The general advice given to anyone who wants to be a writer is to read a lot. Reading does help to improve writing. Brian Kelley says as much in a brief blog entitles "Of Mice and Men" in which he asks of his writing "What about it is memorable and captures the imagination? Even in technical writing, this should be possible".

He gives an example from John Steinbeck's writings hence the "Of Mice and Men" title.

When you read something you enjoy or something that sticks in your mind you need to consider Brian's question "What about this is memorable and captures the imagination"?

If you are able to pin down the answer then you can use it for your own writing. Be quite broad in your reading for the best results.

I don't want to labour the point on reading classics but I will say that classics weren't always classics. They became classics because they possess some enduring quality that has kept them on the book shelves, in some cases for centuries!

If you enjoy reading but were put off reading the classics at school then I have a strategy that I use that may be of use. I generally read one classic to every two of my normal reading material. Sometimes I enjoy the classic so much that the author becomes my normal reading material!

How to treat criticism

Your article is your baby and no-one reacts well to being told they have an ugly baby. One of the hardest things is to accept the criticism but that is something you must learn to do.

Most criticism on SQLServerCentral is constructive even when it gets heated. A lot of that heat arises from the passion people feel about their areas of expertise. That passion is what makes them compelling advocates for their subject and worth listening to.

  • Joe Celko is passionate about adherence to standards
  • Larry English is passionate about data quality
  • Ralph Kimball is passionate about dimensional modelling

Sometimes you have to balance someone's passion with your own dispassion in order to harvest something positive from the discussion.


If one person writes an article as a result of reading this then I will consider this article a success.

The BBC has a motto "To Educate, Inform and Entertain". I think this would be an excellent motto for aspiring writers to adopt.

I try to practise what I have been preaching although some of the points I have outlined are things I aspire to rather than achieve.

It is hard to be dispassionate about criticism. The vast majority will be constructive. Don't be put off by the tiny offensive minority who flame you but go strangely quiet when asked to elaborate.

I will leave you with two thoughts

  • As with all things in life, practise makes perfect.
  • Those who do not try cannot succeed
Total article views: 2827 | Views in the last 30 days: 1
Related Articles

Writing a Technical Article - Structuring Your Article

This is part one of a series on writing a technical article. The advice might apply to non-technical...


Writing a Technical Article – Where to Publish

This is part three of a series on writing a technical article. The advice might apply to non-technic...


Tips & Tricks for DBAs Writing Their First Article

I have been writing full or part-time for nearly 30 years, and I have written and edited hundreds of...


CPU 100% and critical

CPU 100% and critical


Should I write the MCTS 70-431 exam?

Should I write the MCTS 70-431 exam?