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.

Summary

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