This is part two of a series on writing a technical article. The advice might apply to non-technical articles, but I’m focusing specifically with my examples on technical pieces. Other parts are listed at the end of this article. I've been asked often about where I get ideas from. The answer, for me, is everywhere. Every conversation, email, article, almost everything that happens in my life triggers thoughts and ideas, and as a writer, I tend to think about how I would write about things.
That took years of practice, and constant writing to develop that skill, but I've heard similar things from people that don't write daily like I do. However I do have a few ideas and thoughts.
First, anything that you do in your job can be an article. Any problem you solve, any solution you implement, they can be an article. No matter what you're working on, I can likely find a way to write it into a technical article.
Second, remember that you are teaching someone about the technology. You want to consider how you would mentor someone else about this technique. If it's anything non-trivial for a layman in your area, it can be written about.
I tend to focus more on beginner articles, and I think that's a good place for new writers to consider. Different publishers will be looking for different levels of content at any time, and they'll often let you know if your article doesn't meet their needs.
As an example, here are a few things that I've seen happen in my environments and then written about:
- Exceeding the size of a INT in an identity column from over 4B inserts.
- Moving tempdb
- Template use in Query Analyzer
- Routing issues when multi-homing a SQL Server
- Designing a simple database for a specific type of content.
Some of these are beginner, some of them are more experienced, but the topic doesn't matter. Different publishers will have different criteria for what they will publish. They will let you know, and you can work on your article based on where you will publish. SQLServerCentral will publish almost anything while MSDN will be very choosy about which topics they release.
Any problem that you have solved is likely something that plenty of other people have not. And the longer you worked on it, the less information you found on it, the more likely it's a good candidate.
The one thing I caution people against is writing general overviews. Too many people write these, and they often don't add information or knowledge to the world. We each have our own voice, but overviews are so generic that you likely won't reach different people with yours. Instead focus on a specific area and give details. Your readership will appreciate it.
Writing a Technical Article Series
The rest of the series on how to write a technical article.
