Dr. Dobb's Author Guidelines

Most articles that appear in Dr. Dobb's Journal or on Dr. Dobb's Portal web site are written by readers just like you--programmers who have something they're interested in and would like to share it with fellow programmers. In other words, articles can be described as real solutions for real programmers, usually going well beyond the familiar "hello world" type of article. The best Dr. Dobb's articles are those that are grounded in your real-world experiences with programming tools and techniques.

It is important to remember that Dr. Dobb's readers begin receiving the magazine about 4 weeks prior to the cover date. This means that articles need to be complete and in our hands at least 3 1/2 months before the cover date. Likewise, articles that appear online also have a lead time, as we carefully evaluate, review, and edit all articles, whether they appear in print or online. So plan accordingly when submitting a proposal for a particular time.

Send all inquiries, proposals, outlines, abstracts, or complete articles to editors@ddj.com.

• Is Dr. Dobb's interested in my article?
• What kinds of articles does Dr. Dobb's print?
• How do I propose an article?
• How do I write an article?
• How do I send a completed article?
• Whom do I send my article to?
• What happens next?

---

Is Dr. Dobb's interested in my article?

If you're a programmer who has done something you think is interesting, odds are that other programmers will also think it's interesting. Writing for Dr. Dobb's will give you the chance to share your innovations and insights with other programmers who can appreciate what you've done. Dr. Dobb's articles tend to be fairly narrow in focus, looking at a single technique or problem. A magazine article is too short to discuss an entire large development effort, but it's just the right size for discussing how you solved a single, specific problem.

Dr. Dobb's readers are serious programmers who look to Dr. Dobb's Journal for useful information. They read Dr. Dobb's for descriptions of algorithms, specific language implementations, and edifying examples of solutions to more general programming concerns. Many articles in Dr. Dobb's are "task specific" -- they solve a specific problem or provide a unique technique. (Keeping this point in mind helps you focus your writing.)

Most articles in Dr. Dobb's have source code with them, ranging from a few dozen lines to illustrate a particular technique or language feature to tens of thousands of lines implementing a complete application. Good source code is not very useful by itself, however. A good article describes why the source code is interesting. Is this technique faster than other techniques? How does your tool compare to other similar tools? If your program is an implementation of a protocol, algorithm, or data structure, tell us about the protocol, algorithm, or data structure.

Not all articles are about software, however. We publish articles on hardware issues (especially if there is a software component), as well as articles covering legal, social, and business issues of direct interest to software developers.

Dr. Dobb's is both platform- and language-independent. We cover operating environments including  Windows XP/CE/VISTA, .NET, MacOS, UNIX, Linux, and real-time operating systems. In addition to C and C++, we routinely cover Java, Tcl, Perl, Visual Basic, Python, Cobol, Ruby, Fortran, Basic, Smalltalk, assembler, and other familiar (and unfamiliar) programming languages.

---

What kinds of articles does Dr. Dobb's print?

Feature Articles

Dr. Dobb's  has "themes" that tell readers what they can expect in that issue. Feature Articles are responsible for delivering on that theme. Most articles submitted by our readers are considered as possible feature articles. If you are proposing a possible feature article, you should consider what theme issue it might fit. However, our themes are quite flexible, and we'll print a good article whenever we have space, even if it doesn't precisely match that month's theme.

Dr. Dobb's routinely publishes articles on some aspect of embedded systems. These are computer systems which are developed for a specific task, from controlling a car engine to putting a rocket in orbit. These types of systems have some unique requirements: special hardware, new communications protocols, custom operating systems, different languages, development tools, and development methodologies. We're not afraid of block diagrams or schematics, but you should make a clear tie to the software side of embedded systems development. Articles about emulators or real-time operating systems are also appropriate here.

Internet Programming

Especially with the rapid growth of the Internet, software developers are very interested in all aspects of network programming, from client-server database development and distributed operating systems to Web applets and networked coffee machines. This section is your chance to talk about network protocols, systems, and development strategies.

Dr. Dobb's Journal also examines at specific products. Unlike typical product reviews, which give a feature checklist and a "thumbs up" or "thumbs down" conclusion, we want to know what it's like to use the product. This is your chance to tell us about the tools you've used, and how they helped or hindered you in solving specific problems.

Product-focused articles vary in their approach. Some focus on a particular problem, and show how to solve that problem with different tools. Others focus on a particular, little-known aspect of a common tool and show how it can be useful. Some of our most popular Examining Room articles show how to combine two or more tools to solve a particular problem. Often, this involves circumventing certain mis-matched features, taking advantage of different strengths of otherwise competitive products, or taking an unusual approach to a problem, one that might not have occurred to someone else.

Like all of our articles, product-oriented articles usually provide a healthy dose of code. Those who already own the products can put that code to work immediately, and those who are assessing it can use the code to take a firsthand look. Your fellow programmers are looking for your expert knowledge and experience in using a tool under real-world conditions; this is more valuable than just knowing that a tool exists.

Ultimately, the reader should walk away with a sense that he or she has actually used those tools. Although you're certainly free to throw in your own recommendations, this hands-on approach should allow readers to make their own conclusions about whether that tool will work for them.

Columns

For the most part, individual columns either in print or online are written by our contributing editors. However, we do look for guest editorials for our "Alia Vox" column.  We also are interested on expert perspective in our "Conversations" Q&A section, which asks questions about technologies related to the monthly theme. Q&A and guest editorials should be no more than 750 words each. We're also keen on who readers are and what they do in our "Developer's Diaries" section. If you would like to participate ý or know someone who deserves to be highlighted, let us know. Contact us at editors@ddj.com.

---

How do I propose an article?

If you have an article idea, you should first send us an article proposal. This is a short statement (about a page) that says what your article will be about. You can mail it to our office or e-mail it to editors@ddj.com. Be sure to give us several ways to contact you (such as phone number, e-mail address, fax number, and mailing address). We'll look at your idea and get back to you, usually within a month. And if we accept the article, we'll also need a short bio and a photo of you to accompany the bio.

Although many people simply write their entire article and send it to us, there are several advantages to sending us a proposal. We can look at your idea and possibly suggest a particular slant you hadn't considered. We can also help you to organize the article.

---

How do I write an article?

Writing Style

Write as if you are giving a brief, informal talk to a group of coworkers. You want to be concise and well organized because you don't want to waste their time, but you don't want to be too stuffy or formal because you know them. If there's an issue or example that's important, but slightly off topic or more difficult, consider separating that into a 300-word sidebar.

We encourage you to describe in depth all of the algorithms your program uses. Go into as much detail as possible. Your article should provide something useful to the readers, even if they never look at the code. Ideally, your article should begin with a concrete, general perspective on how the algorithms can or have been used practically.

Teach something in your article. Though Dr. Dobb's readers are, by and large, a knowledgeable lot, many of them are reading your article to learn something new. Consequently, your article should contain more than a technical description of the code. It should explain how a program works and why you made each important programming decision. Describe a few basics before jumping into a very technical discussion. Of course, you can't explain everything about your topic in a short magazine article. Nevertheless, a reader should be able to understand the basics of how your program works by reading your article.

Address the issue of portability. Even if your program is very machine specific, your underlying algorithms and tricks will transfer. Say how.

If applicable, provide a bibliography at the end of the article that includes a description of each of the referenced sources. It is essential that you include the full bibliographic information of all sources! This means title, publisher, date of publication, author, issue (if a periodical), place of publication, and any other information that is pertinent.

Do not hype your product. An article that amounts to little more than a product description or lengthy press release will have to be rewritten.

Parts of a Typical Article

A typical article contains several parts:

Article text

Articles usually are abpit 2500 words of text. However, you should make your article the right length for your topic. The most common problem with submitted articles is that they are too long, with a lot of details that don't really belong.

Text within the main article should stand alone, rather than relying on the illustrations. For example, you should first explain a topic then refer to the illustration: "Although the Trend function is useful in some applications, a more flexible approach is to use the equation <I> as a matrix operator, as shown in Figure A."

Tables

Tables are a concise way to give particular types of information. Give each table a clear, detailed caption, and refer to it in the text by number. ("As Table 1 shows, ...")

Figures

Illustrations and screen captures offer an opportunity to lure anyone looking through an issue into reading your article. They can also provide succinct summaries of complex ideas. Since we redraw most figures anyway, to conform to our size and style requirements, you should not worry about making your images very high quality. Many authors prefer to sketch them by hand and fax or mail them.

Please provide any screen captures you think are relevant. We don't necessarily have the time or equipment to run your program and make our own screen captures. Screen captures should be in a common graphics format (such as GIF, PCX, TIFF, or BMP)

Please don't embed your images in a word-processing document.

Examples

Short pieces of code (less than 20 lines) can be placed near the text as Examples. Like Tables or Figures, they should have clear captions and be referred to by number. ("A better approach is to use Knuth's algorithm, outlined in Example 1.")

Tables, Figures, and Examples are placed at the top or bottom of the page in the magazine. Although we do try to place them near where they are needed in the text, space constraints sometimes force them onto a later page. Keep this in mind as you write.

Listings

Longer pieces of source code are printed at the back of the magazine or on the pages following the article. For space reasons, these should be less than about 400 lines. Often, these will be a few important excerpts from a longer piece of source code.

Complete Source Code

Although we can't publish the complete source code to large projects (or binaries), we do make this code available to our readers in many ways, including our FTP sites, the Web, and so on. You can (and should) refer to this code in your article, but be careful since the reader will not have the source code immediately available.

Other Information

Please include suggested headline (title), decks (subtitle), subheads (section titles), and a two-sentence author biography. Also, please provide short captions for all examples, figures, and tables. All should be in active voice.

General Writing Guidelines

Keep your writing informal and concise. Here are some concrete suggestions:

• Use the active voice when possible. (Avoid excessive use of forms of "to be." For example, don't say "The problem is that XXX", just say "XXX is a problem.")
• Don't use "we" or "our" unless there are multiple authors; use "I" instead. Similarly, refer to the reader as "you." (For example, "Although I chose a simpler approach, you might find the full algorithm necessary in some situations.")
• Avoid needless duplication. Read your article carefully and ask yourself whether each sentence and paragraph adds to the article or simply duplicates a point you've already made.
• Many writers find it useful to put their article aside for a few days after they write it, and then come back and read it again.
• Get a friend to read and comment on your article before you send it to us.
• Make sure that every Figure, Table, Example, or Listing is referred to somewhere in the article.
• Don't put lengthy code excerpts, tables, or figures into the text. Any piece of code longer than a few words should go into an "Example" or a "Listing" (see above.)
• Refer to parts of a listing by using function names or other apparent locations ("...the definition of variable cpLine..."). Do not use line numbers.
• If you refer to source code that isn't going to be printed in the magazine, use the name of the source file and the function or other apparent location.

Take the same care in preparing your Listings that you do in polishing your article. People will be reading your source code; make sure it is clearly formatted, no more than 70 columns wide, and reasonably commented.

How do I send a completed article?

Once you have something you like, it's time to package it all up. Although we accept articles in a variety of formats, here are some of our preferences:

• Save each figure, table, example, or listing as a separate file.
• Build a ZIP/PKZIP archive containing the separate files, then e-mail it to us.
  
• Don't forget the complete source code for inclusion on our FTP site.
• Provide all listings and examples as plain text files.
• Provide graphics in a common graphics format (GIF, JPEG, PCX, BMP). Don't worry about making it perfect; we recreate most graphics so they look as good as possible. However, if you have screen shots or the output of a program you're demonstrating, be certain to tell us, so we won't unintentionally alter them.
• The article text should be provided in a plain text format, which is what we often work from. Especially if there are formulas or other special symbols, please provide a hard-copy printout as a reference. Word processor files are often useful, but don't waste much effort formatting them, and please don't embed figures in the word processor file.
• Remember to include your name, work and home address, work and home phone numbers, e-mail address, and any other information that might help us contact you. (We can't publish your article unless we can contact you and mail you a contract.)

To include an article in a particular issue, we request that you give us the final article at least four months ahead of the cover date. It typically requires at least a month to review and edit an article, another month to typeset and prepare the magazine, and our magazine actually ships to subscribers one full month prior to the cover date.

---

Whom do I send my article to?

If you've first sent a proposal, then you should already have the name and address of an editor you're working with. You should send it directly to them.

Otherwise, you can mail them to "Editors" at our office or e-mail them to editors@ddj.com.

---

What happens next?

Once we receive an article, we go through a number of steps to evaluate it and prepare it for publication:

• If you send us a proposal, we'll assign an editor to work with you. That editor will discuss your proposal with you and help you refine your idea.
• After we receive the finished article, we'll decide if we want to publish your article. If we do, we'll send you a publishing agreement. This agreement tells you that we want to publish your article; it's not a guarantee that we will publish your article. The publishing agreement will specify the fee you will receive for publishing the article (yes, we do pay for all articles in Dr. Dobb's), along with the rights we need to acquire. Essentially, we request the rights to publish your article and accompanying code in Dr. Dobb's magazine, include it on our annual DVD, publish it on the Dr. Dobb's web site, and so on.
• One of our technical editors will carefully go through the entire article. They'll check that your article makes sense, and may rewrite sections of your article to make it clearer. Our technical editors are experienced software developers and writers, and our authors usually find their work is improved in this process. If an article requires more extensive changes, the editor will frequently ask the author to make the changes. Please be patient at this stage. Our technical editors are very careful; it sometimes takes a full week to edit a single article. As a result, an editor that has three or four articles to work on may not be able to give you useful feedback for a while.
• Our Editors will take the edited article and decide which issue it goes into. Notice that although the contract specified a particular issue, that was only a guess.
• About three months before the cover date, the article goes to our production staff. They produce a galley proof of the article and send it to the author for any final changes. They also create a mock-up of the magazine containing all of the articles. This mock-up is thoroughly edited by our entire editorial staff, which checks every article for grammar, style, punctuation, and other minor problems. Any corrections the author makes to the galley proof are incorporated at this stage.

There are times when our office is extremely busy, so we will sometimes not be able to respond to a proposal or article for several weeks. If you've not heard anything for more than a month, however, please call us.