s a kid/teen, I wrote short stories and read tons of magazines: Boy's Life, Baseball Digest, Twilight Zone, and MAD Magazine. My parents knew how to keep me occupied on long road trips.
In college I studied English, read newsletters, and wanted to write novels, though computers also intrigued me. People told me I should go full force into the software industry. I knew BASIC and dBase and C, but thought doing so would mean walking away from creativity. Then the spring of 1987 happened.
I read a series of lengthy articles on dBase compilers and C programming in the old PC Tech Journal and Dr. Dobbs Journal. I studied them over and over until I could quote them from memory. The examples helped me fill in the gaps on specific technical areas.
But beyond that, I also sensed a creative tone, a healthy swagger in the writing that inspired me and helped me realize how much fun I might have in this industry. Later that summer I decided that this was my calling: developing, and hopefully writing. Many people can point to formative experiences that shaped their career: that was mine. Twenty years later, here I am (with a long list of people to thank).
A few readers have sent me emails, describing how they've used content from my Baker's Dozen column in their applications. To all of you, I'm very grateful. All these experiences reinforce my belief in the value of articles as a great medium to help get people up to speed with something.
Additionally, some who are interested in writing have asked me questions about building articles. So I set out to share my thoughts and my M.O. (in my case, "Madness Operandi"). As I begin writing my ideal recipe for building an article, I had to confront the fact that I haven't always heeded my own advice. So my 13 tips for building an article are not only suggestions for new writers, but also as a reminder for myself (in other words, therapy for the therapist!) Here we go:
- You need to start with a strong idea of what you want to discuss, whether it's something on Generics or WCF or extender classes. And it better be something you are passionate about.
- I own enough music CDs to start a record store. Some albums are concept albums, some aren't. I often think of articles that way-some use a small demo application as the vehicle for the article content, while others present a series of independent code listings/snippets. Keep that in mind when you decide on your code samples and how you want to present them.
- Build a simple outline of the main points you want to cover. Also, write a paragraph that introduces the article.
- Share your article ideas with your colleagues. Some writers are only comfortable using their own vision, but I prefer to (at least) solicit input. Some of my friends have given me great ideas, all for the mere cost of a steak dinner.
- Flush out the outline of your article to identify in detail the main points you intend to cover. Determine how many figures, tables, and code listings you'll need. Don't be afraid to look at published articles to get some general ideas about article structure. In particular, study articles by Ken Getz they're immaculate.
- Remember: CoDe Magazine is about CODE. So plan out your code listings and snippets-and hopefully, lots of them. Some readers will only skim your article and go straight for the code. So make sure your code samples can stand on their own. The late Drew Speedie excelled at this.
- This is a personal viewpoint: A cluttered workspace indicates a cluttered mind. I find myself more productive when my office/workspace is clean and organized.
- Write your complete first draft as quickly as you can. You'll need time to revise/edit the first draft. This is where the real work begins.
- Walk away for two to three days and resume your normal work/life. During your time away from the first draft, you'll begin to think about things you forgot or missed. Make sure to write down, or type, or even record everything that pops into your head. You want to revise the first draft with notes that you've subconsciously processed while you've been away. This may sound a bit hokey but it totally works.
- Go back and make your changes. Then re-read your article.
- Take another day or two away from it. Then come back to it, go into a quiet room, and read the article out loud, as if you were reading the script for a formal presentation. This can help you spot issues with flow.
- Check your code samples one last time and make sure they work.
- After you submit your article, you'll surely receive all sorts of edits from the magazine's editors. CoDe Magazine has fantastic editors like Rod Paddock and Erik Ruthruff. Make sure you listen to their suggestions, because they know how to take an article and make it better.
So I'll try to follow my own advice as I tackle my next set of articles, which will include productivity tips for SQL Server 2005, ASP.NET, the new ADO.NET Entity Framework, and a comparison of Crystal Reports and SQL Server Reporting Services.
Peace, and great software.
Kevin S. Goff
|Editor's Note: This article was first published in the July/August 2007 issue of CoDe Magazine, and is reprinted here by permission.