Writing for MSDN Magazine: A Primer

Ever wanted to publish an article in MSDN Magazine? If so, here's what you need to know.

First, send us your idea: our submissions email is mmsubmit@microsoft.com. Make the Subject Line of the email "MSDN Article Query". As part of that email, we'll need the following information:

• A tentative title for your proposed article.
• A concise and informative blurb (2-3 sentences) for your article. Write this as if the text would appear beneath a linked Web headline.
• A brief description of your topic, not longer than half a page.
• Two or three takeaways that developers will get after reading your piece (one sentence each).
• The intended scope of your coverage (for example, Web applications, application architecture, database programming, mobile applications, security, etc.)
• The programming languages for your code samples, if code will be included in your article (C#, VB.NET, F#, C++, IronPython, etc.)
• Technologies discussed (ADO.NET, Parallel Extensions, Silverlight, Windows, DirectX, etc.), together with their versions.
• A bio. Bios are normally two to four sentences long. Emphasize your work with the subject matter about which you're writing. Note that it's OK to include a reference to your blog or website.
• A list of published articles, if any.
• Whether you've previously published or have granted rights to this proposal to another publisher, whether in print or on the Web.

Typical article length is between 2,500 and 4,000 words (not including code samples). We’ll make every effort to review your proposal and give you an answer in a timely manner, but we don't guarantee a response within a specific timeframe. If you've submitted a query, however, and haven't heard back in a few weeks, by all means send a follow-up email asking about it.

Some articles have a greater chance than others of being published. Here are some ways to increase your chances of having your proposal accepted.

• Relevance. Even if writing about a niche topic (like robotics or gaming), there are probably aspects that that have broad programming applicability. Original, creative solutions to common problems have better chances than proposals whose applicability is narrowed by a set of particular constraints.
• Takeaways. It's important to spell out clearly what practical, applicable knowledge readers will have after reading your piece. For example, a good takeaway is “The reader will be able to determine which UI technology (RIA, Web, Mobile, Desktop) is better suited for a particular use case”. A less-useful takeaway would be something along the lines of “The reader will learn that WF 4.0 comes with new namespaces for some re-implemented features.” While that is useful in an educational sense, it's no actionable information. Instead, show some real-world examples of how those namespaces can streamline development.
• Brevity and clarity. Make your query stand out by keeping it tightly-written and clear. If your email pitch is rambling and unfocused, with multiple spelling errors (indicating that you couldn't even be bothered to spell-check it) and no clearly-defined goals for the article, we're more likely to assume the worst about you as a writer. Do not underestimate the importance of a good query. Keep it short and to the point, and show us that you've got at least some basic writing chops.
• Platform timeliness. This magazine earned its reputation by being one of the few channels covering, in great depth, current and upcoming technologies. You don't need to be told that technology moves fast; by the same token, few developers move at Microsoft's speed.
  You don’t necessarily need to cover latest features to increase your chances of being selected. What we actually avoid in MSDN Magazine is to publish articles on aspects that were superseded by new ones. So, in .NET 3.5 for example, WCF incorporated support for syndication (RSS, ATOM) not available before. If you are dealing with an example that involves syndication, you must have a good reason to deal with it on your own instead of using WCF Syndication. “Because it’s not available on earlier versions of .NET” won’t be a reasonable defense regarding our timeline premise.
• Exclusivity. This magazine publishes original works that have not been previously made public. This doesn't mean that you can't, for example, write an article based on a previous blog entry from your website. If, however, half of your article is a verbatim reproduction of that blog entry, that would be unacceptable. If the story has appeared, in part or whole, somewhere else, we will also reject it.
  It's fine to add value to your article by consolidating information from multiple sources, correlating information, contrasting and comparing, as long as you credit all your sources as use them as building blocks to make your article better. Making too much of your piece dependent on other sources, however, is likely to result in your story being rejected.
• Writing Experience. We do not reject queries from unpublished authors out of hand. We understand that most of you are, first and foremost, coders, programmers and software developers. As such, we don't expect Shakespeare or Hemingway.
  If you have published before, it's a mark in your favor. Even that, though, is no guarantee that you are a capable writer. If we accept your proposal, we'll work hard with you on getting your article up to our publishable standards. Be aware, however, that the editing process can be painful for new (and even experienced) writers. Your story could go through many drafts, with lots of rewrites necessary on your end. If you're not prepared to put in the work, reconsider your proposal before you send it in.
• Payment. This magazine pays on publication -- that is, after your article runs, we cut you a check. So it is possible that we could assign you an article, which we would eventually decide not to run in the magazine. If that's the case, you would not get paid for that article.
  In practice, this hardly ever happens. But know that it could. If you plagiarize something in your article, or it's so poorly written that it's not salvageable, for example, we will kill the story and you won't get paid.
  Payment is worked out with the magazine editor in chief in advance of the story being assigned. There is no standard fee; payment is determined on a story-by-story case.

As you can see, getting published in MSDN Magazine is no easy thing. But it can be rewarding, for those with good ideas, some writing talent, and the desire to work hard with the editorial staff to shine their articles to a high gloss. If you're interested, we'd love to hear from you.

Sincerely,

Diego Dagum, Editorial Director
Keith Ward, Editor in Chief