 DR. DOBB'S JOURNAL AUTHOR GUIDELINES

 The Territory

DDJ Readers are serious programmers. They read DDJ for descriptions of
algorithms, specific language implementations, and edifying examples of
solutions to more general programming concerns. Many articles in DDJ are "task
specific" in that they solve a specific problem or provide a unique technique.
(Keeping this in mind helps you focus your writing.) DDJ is primarily a software
magazine, but that doesn't negate the importance of articles featuring hardware
and hardware-related subjects. The ideal article in this category integrates
hardware and software considerations.

 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.
Sidebars provide an excellent tool for giving the readers specific examples or
for going into greater depth on a subject that is more difficult for the average
reader.

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 DDJ 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
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. It's very helpful if you include
bibliography that mentions other applicable published works that aren't
referenced in your article.

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.

 Some general writing guidelines

*  Use the active voice when possible. (Avoid excessive use of forms of "to
be.")

*  Write captions that are sufficiently detailed to explain your illustrations
and screen captures, instead of merely providing a label. Remember that
illustrations offer an opportunity to lure anyone looking through an issue into
reading your article.

*  Text within the main article should standalone, rather than relying on the
illustrations. For example, it is preferable to 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 <...> as a matrix
operator, as shown in Figure A."

*  Please include suggested headline, decks, subheads, pull- quotes, and a two
sentence author biography. All should be active, which generally requires use of
a verb.

 Focus

Each issue of DDJ has a theme. While we are always interested in good, technical
articles on any subject, we are particularly interested in articles dealing with
a theme of an upcoming issue. If you have an article idea, the best way to find
out if it is workable is to call the editor and ask. The current number is
415-366-3600 (fax is 415-366-1685), and the editor-in-chief is Jon Erickson. You
will then most likely be asked to submit a written proposal of your idea.

Remember as you plan your own writing schedule that if we get your article well
before the submission deadline, there will be time for rewriting or
modifications. If you send your manuscript under the wire and it needs changes,
it probably won't be considered for publication.

 Examining Room

The "Examining Room" is where DDJ takes a look at specific products. The
"Examining Room" deviates from the typical product review that ticks off the
features of a product and gives a "thumbs up" or "thumbs down." Instead, the
ideal Examining Room article is an in-depth approach that centers around, for
instance, the development of some application.

As such, the review should provide a healthy dose of code. Those who already own
the product will thus be able to put that code to work immediately, and those
who are assessing the product can use the code to take a firsthand look.

As with the "Programmer's Workbench," the "Examining Room" exposes the strengths
(and weaknesses) of the product through the development cycle. But, since it is
difficult to contrive an article that exposes the entire feature list of a
product, a section should be included that highlights other features. The
article can, therefore, focus the example on some nifty routine, utility,
algorithm, or the like.

Although the purpose is not (necessarily) to give a recommendation, authors
certainly have the freedom to "throw in their two cents". But keep in mind that
this hands-on approach to the review should allow readers to make their own
decisions by giving them a sense of what it's like to actually use the product.

If all of this sounds like a lot of work, DDJ occasionally makes room for
capsule reviews in the neighborhood of 500 to 700 words. Reviews of books fit
nicely in this category. Books to be considered are those that are viewed as a
"valuable" resource.

 Programmer's Workbench

The "Programmer's Workbench" gathers together a complete environment in order to
develop a complete application. A typical workbench might include tools for
prototyping, code generators to support the API of a complex GUI, add-in
libraries so that the programmer doesn't continually reinvent the wheel, and
other development tools such as debuggers and profilers.

If, for instance, you're just getting involved in writing 32-bit code for the
386 under DOS, you'll quickly learn that the 386 compiler must reside in a
16-bit environment and that the code produced is designed to be run in under a
DOS Extender. If the Extender wasn't on the original shopping list, it's back to
the store. The "Programmer's Workbench" highlights the tools that are required
and those that are fluff.

But rather than simply presenting a shopping list of tools and a discussion of
how they interact, the "Programmer's Workbench orchestrates the tools on the
workbench to develop something that is real. And in the process, the strengths
of each tool are revealed. Ultimately, the reader walks away with both the sense
that he or she has actually used those tools, and the code to experiment
further.

 Submitting the Article

Send your material in pure ASCII, without control codes, and include a
double-spaced hard copy of the text, listings, and figures, tables and examples.
Put your name, address, and both home and work phone numbers on the first page
of the manuscript. Each following page should have your name and the page number
in a header or footer. The disk should contain one file with the text of the
article (LastName.txt), one or more files with listings (LastName.ls1,
LastName.ls2, etc.) and one file with any tables (LastName.tb1). We prefer
either PC compatible (5 1/4" DS/DD) or Macintosh disks. If you like, you may
send your article electronically via the DDJ listing service, or by CIS, but if
you do send in this way, please also mail us a hard copy of the article.

 Preparing the Listings

All Listings must be submitted as both hard copy and on disk. The disk file
should be straight ASCII, free of control codes, ideally 70 columns in width, no
wider than 80 columns. The listing number and the page (i.e., Listing 1-1,
Listing 1-2, etc.). You should take the same care in preparing your listings as
you take with your article. The listings should be well formatted, easy to read,
and adequately commented. Your comments should explain things that aren't
obvious in the code itself. We are much more interested in making your program
readable than we are in saving space.

Please call out your listings at the appropriate place in the text (for example,
"see Listing 1"), and be sure to refer to them exactly the same way they are
labelled elsewhere. Don't use page numbers when referencing a particular section
of code; use subroutine names (for example "... at the top of subroutine
foobar()...") or line numbers.

All "Examining Room" and "Programmer's Workbench" suggestions are to be sent to
the attention of Michael Floyd.

Please send article suggestions to:

 Jonathan Erickson
 Dr. Dobb's Journal
 M&T Publishing
 501 Galveston Drive
 Redwood City, CA 94063

 FAX # 415-366-1685
 Phone # 415-366-3600
 MCI Mail: DDJ
 CompuServe: 76704,50
