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,
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.
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
- 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
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
- 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
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,
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
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.
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
- 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
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
He gives an example from John Steinbeck's writings hence the "Of Mice and
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
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
- 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