July 2003 - Posts

Just My Luck - XQueryServices.com is Down
28 July 03 11:06 AM | Scott Mitchell

It's what every technical writer fears: the moment you complete your latest book/article, what you write about either becomes obsolete or impossible for people to use. This has happened to me a couple notable times before with book projects, but recently revealed it's ugly head with my latest 4Guys article Querying XML Data with XQuery. In this article I discussed XQuery, a syntax for querying XML documents. While XQuery has yet to reach a w3c standards point, it is very stable and Microsoft has (had?) released a .NET XQuery engine, available for free at XQueryServices.com. The article demonstrates how to use the XQuery engine from XQueryServices.com on an ASP.NET Web page. I published this article on 4Guys last week and, naturally, XQueryServices.com is now down.

If anyone from Microsoft is reading this, or if anyone has a Microsoft contact in the XML department, I have a few quick questions I'd love to have answered:

  1. Is XQueryServices.com down for the count, or just temporarily? It appears to be down right at this moment (Monday, July 28 11:00 AM PST), and this messageboard post makes it look as if it's been down for at least 24 hours prior to now. So, what's the long-term status?
  2. Can I publically provide the xquery.msi file that folks can download from XQueryServices.com? Currently, the article has a link to download this MSI file from XQueryServices.com, but given the less than reliable nature of the XQueryServices.com Web site, I would like to host the file on 4Guys - is this acceptable?

Thanks to anyone who can help!

Filed under:
RSS Feed for 4GuysFromRolla.com
25 July 03 05:52 PM | Scott Mitchell

I have finally gotten around to adding an RSS feed for 4GuysFromRolla.com. The feed lists the articles currently on the Recent Headlines page, and includes the the article's title, a lengthy description of the article, and a link to the article. You can start snagging the RSS feed at: http://aspnet.4guysfromrolla.com/rss/rss.aspx

Also, for those who utilize ASPMessageboard.com, there is an RSS feed of the 20 most recent posts.

Happy Programming!

Filed under:
A Bit About Blogs
25 July 03 10:24 AM | Scott Mitchell

CyberAtlas has a short piece on blog statistics worth checking out. One statistic worth noting is that only 4% of the online community even reads blogs, while only 2% of the online community has created a blog. I would expect these numbers to grow as blogging becomes more pervasive.

Also worth checking out is Dave Pollard's Secret of Breakout Blogs. In this piece, Dave discusses what he views as the three most important aspects for creating an extremely popular and trafficked blog. To quote the article:

  1. A memorable theme or style or some other attribute that gives your blog 'stickiness', so people remember it and come back regularly after they see it the first time,
  2. A well-tested and consistent writing process that has been proven to build allegiance and regular readers, and
  3. An infectious quality that leads readers to recommend your blog to their readers in words that their readers relate to.

I have some random thoughts on blogs, blog stickiness, and the utility of technical/informational blogs that I plan on espousing on in some future entry.

Filed under:
My First Article in the MSDN ASP.NET Section is Up!
23 July 03 10:01 PM | Scott Mitchell

My first aritcle (of seven) for Microsoft's MSDN Web site's ASP.NET section is now live. Titled Deciding When to Use the DataGrid, DataList or Repeater, this article examines the differences and similarities among the three data Web controls, and discusses when you would want to use each. To help ascertain what control is the best, the article outlines three metrics to consider:

  1. Usability, from the end-user's perspective,
  2. Development time required for implementation, and
  3. Performance

I've got a really cool article coming up soon on the ASP.NET section on building an online RSS aggregator using ASP.NET, XML, and XSLT.

Filed under:
Tips for Giving a Presentation
19 July 03 01:07 PM | Scott Mitchell

Stumbled across Scott Hanselman's blog entry, "Tips for a Successful MSFT Presentation." This blog entry was from January 2003, but is totally worth reading if you give talks or plan on giving talks.

I am no expert on giving technical presentations, my experience being limited to the classroom setting, a handful of user group presentations over the years, and an ASP.NET conference. Does anyone know of a Web site for technical presenters similar to ScottOnWriting.NET?

Writing for a Technical Web Site
19 July 03 12:46 PM | Scott Mitchell

If you've ever considered writing a computer trade book, or would be interested in writing magazine articles, a great and easy way to start your writing career is to write for one or more technical Web sites. Specifically, you'll want to write for a Web site that focuses on providing technical resources for the particular technology you're adept at, prferably one of the more visited ones that strive to have high quality content.

Now, there is some good news and bad news about writing for a technical Web site. First, the good news: most technical resource Web sites are eager for content and will happily accept a submission from a first-time author. The bad news: many technical Web sites, even those run by big companies, don't pay for content. This makes sense, of course, since many of these sites essentially give away their content for free. Typically, the only Web sites that will pay for technical content exclusively for their online division are those that charge people to view such content - such as ASPToday.com and CSharpToday.com, prior to Wrox's meltdown - and companies who have a ton of money, such as Microsoft. (All of this should come as no surprise if you've read my post on The Economics of Book Writing; there's not a lot of money in technical writing, unfortunately.)

Despite the direct lack of monetary compensation, writing for an online technical resource can pay off in many indirect ways. First, it exposes you and your writing to hundreds to hundreds of thousands of developers (depending on the popularity of the Web site you end up writing for). This exposure can provide good feedback on your writing style; while rarely will you get an email from a reader saying, "I think your setnence structure could use some work," you will get emails with questions on what you write, such as, "I want to do this, which is similar, but am stuck," or, "I didn't understand it when you said xxx." Think of these questions as breadcrumbs, as they leave a discreet trail to what you need to work on in your writing style. If you get a lot of, "I didn't understand this part"-type questions, perhaps you're not focusing enough on English explanation and instead jumping into the code too quickly. Or maybe the organization of ideas is too confusing, hence the article doesn't flow cleanly from one section to the next.

Writing for a Web site also helps you establish a relationship with the person or party that maintains the Web site. If this is a Web site for a book publisher, these contacts can be invaluable. If this is a Web site run by a prominent leader in the technology's online community, you can utilize your relationship with the Web site owner to make more contacts and become more involved in the online community yourself.

Getting Started
Clearly the first task in writing for a technical Web site is deciding what Web site you would like to write for. Make a list of those Web sites that you visit regularly for your technical information, and then scour through the Web site to see if you can't find any links for information on how to write for the Web site. Many technical Web sites will have a, "Write an Article" link somewhere on their homepage, with instructions on who to contact for more information. For example, on the Web site I run, 4GuysFromRolla.com, there is a link on the homepage titled, "Author an Article." This hyperlink leads to a page that discusses the writing process, deadlines, the format the submitted article should be in, and so on. If you have trouble finding such a link on the Web site you want to write for, you can always email the site mainters directly and ask them about writing opportunities.

While there are likely many technical Web sites out there that have content on the technology you wish to write about, I would strongly encourage you to try to write for a Web site that puts out only high quality articles. Many Web sites, I've found, will publish just about any contribution sent their way, with little or no editing. Try to avoid these Web sites for two reasons:

  1. If the Web site will publish your content without making any edits or changes or suggestions or comments, how will you sharpen your writing skills, and
  2. Typically such Web sites have an overall lower quality of articles; no need in associating yourself and your writing with such a Web site!

Once you have decided that you want to write one or more articles for a particular technical Web site, the first step is not to contact a Web site and say, "I would like to write some articles," the first step is to come up with several ideas for articles, and then contact a Web site! Coming up with ideas can be hard, and you shouldn't try to offload this responsibility on the people running the Web site. (Of course, some Web sites might have a particular idea/topic they would like you to write on; however, don't assume this is the case, and come up with your own ideas first.) Once you have your ideas in hand, and you know the Web site you want to write for, pitch your ideas and see if you get any bites.

Writing the Article
Before you begin writing, make sure that you have communicated with the Web site's editor and that you know the answers to the following questions:

  1. What format should the article be written in? HTML? Word? Text? Any of the above?
  2. How should the article be submitted when completed? Should it be emailed to the editor? Is there an online submission form?
  3. When is the article expected? Some Web sites will pose a deadline, saying, "Please have your article completed by so-and-so date." I've found not too many take this approach, seeing as they are paying you $0.00 for writing the article.
  4. What is the article about, specifically? How long will it be?

I cannot stress the importance of getting these four questions answered and following the answers precisely. If you submit an article in the wrong format, or submit it in an incorrect manner, or vary from the topic that you and the Web site editor agreed on earlier, you will unquestionably make the editor's process more difficult, which means the editing process will take longer and you will get on the editor's bad side. This is not a good place to be if you want to write for this Web site again in the future! :-)

Also, a good question to get answered from the Web site editors is, "What is the process after I submit the article?"

When actually sitting down to write the article, be sure to follow these recommendations. Try to tailor the article to the Web site's intended audience. That is, if the Web site caters to developers new to the technology, make sure to explain the topics in your article in great detail, and to provide analogies, diagrams, and other useful aides where appropriate.

Submitting the Completed Article
Once you have finished writing the article and have submitted it, the editing process should begin. The editing process for Web sites varies on a site-by-site basis, from non-existant to a full-blown editing cycle typical of the editing cycle in book writing. If you chose well in deciding what Web site to write for, there will be an editorial review of your content. Usually within a couple days to a few weeks, you'll either be informed that your article is acceptable and that small edits have been made, or you might get your article back and be asked to make some changes before it is published.

Regardless of the editorial process and their results, if you are an aspiring writer, you should definitely take advantage of this situation and ask the editor for tips on how to improve your writing. While the Web site editor, for certain sites, might be a full-time developer who does the Web site on nights and weekends as a hobby, she likely has seen hundreds of submitted articles, and can help you in assessing your writing prowess.

Assuming the editorial process completes, and you end up getting your article posted online, be sure to first pat yourself on the back, and then start thinking about future articles! :-)

Filed under:
Technical Know-How is Important, But Not Paramount
15 July 03 12:06 AM | Scott Mitchell

Imagine that you were in dire need to learn a particular aspect of some particular technology. In your research for an answer to your question you arrived at two articles written by two different authors with polar writing and technological abilities. If you only had time to read one of the two articles, what do you think you, personally, would benefit from more:

  1. An article writen by an author with extreme expertise in the particular technological field, but with horrendous writing skills, or
  2. An article written by an author with strong writing skills, but only an average grasp of the technical material?

If you answered (1), then I would wager you've been lucky enough not to stumble upon such an author in the past. As editor for 4GuysFromRolla.com, I have had hundreds of articles submitted by hundreds of authors from around the world. In reviewing these, I have seen both ends of the spectrum, and everything inbetween. Clearly the worst article is one written by an author with a poor understanding of the technology and lackluster writing skills, but a close second worse is one written by someone with a keen understanding of the technology, but without the writing skills to transfer his immense knowledge from his brain to the written word.

If you think about it for a moment, it makes complete sense why the writing prowress of an author is of paramount importance: even if you know it all, others cannot benefit from your knowledge if you cannot adequately express your intellect.

Improving Your Writing Skills
While everyone will agree that one can improve their technological skills in a particular field, I've found that many don't seem to think that they can improve their writing skills. While really, really good writing is an art form, and can likely not be learned, but rather must be innate, good writing is a skill that can be learned as easily as good programming skills. (Note: those who are really, really good writers, don't use expressions like, "really, really.")

So how do you learn to become a good writer? Well, how did you learn to become a good anything? Through:

  • Practice,
  • Mimicking those who you know/think to be skilled at the thing you're trying to learn,
  • More practice,
  • Learning from the advice/suggestions of those who have come before you, and
  • Even more practice!

Learning how to be a good writer is no different. Here are some random suggestions from yours truly, little bits of advice I've picked up over the years either from others or things I've learned on my own:

  • Before you write the first word, write down in a sentence or paragraph, or half-page synopsis what you are wanting the reader to learn and what your content aims to show. (The duration of this depends upon the breadth of the content. For example, a short online article needs just a sentence or two. A book could take half a page or more.)

    Imagine that you wanted to write a short introductory article on XML. Your synopsis might look like:

    "This article will introduce the reader to XML, covering the benefits of XML, what problems it overcomes, and the XML formatting rules. The article will also examine some simple common use cases for XML, such as sharing data between disparate platforms."
  • After you write the synopsis, but before you write the first word, create an outline. Start by filling in the top-level items (the I, II, III items) before filling in any particular top-level items' sub-items. After you have created the top-level items, return to the synopsis and ask yourself, "Will the reader learn what I want them to learn given this high-level outline? Am I covering the material I set out to cover?" Make any needed changes to the top-level items at this time. An example outline for our XML article might look like:

    I. XML - What is It?
    II. Motivation for XML
    III. Benefits of XML
    IV. Common XML Use Cases
    V. XML Formatting Rules

    Also consider reordering top-level items. Try to place yourself in the reader's shoes, and ask yourself if the ordering makes sense. Would it make more sense to move the IV item after V? Or perhaps IV should be moved directly after I. Its optimal position depends on your audience, their experience level, and what they are trying to get from your article.
  • Once you have shored up the top-level items, start adding sub-items to the various top-level items. I usually don't aim for a too granular amount of detail here; rather, I usually go only one or two levels deep (like A, B, C sub-items and then i, ii, iii sub-sub-items).
  • At this point, you are ready to begin writing. The first thing you will write, even if you forgot to include it in your outline, is an introduction. The article's introduction will essentially be restating the synopsis we wrote down to begin with, but in more detail. Next, for each high-level outline topic, you should start the discussion with an overview of what will be covered in that high-level topic.

    Think of a technical article as a journey for the reader, one that ends with a new piece of knowledge.1 The introduction for each section is akin to directions: it summarizes the journey in a short, concise manner, giving the reader an quick overview of where their trip will take them, and what they can expect to encounter.

    When you complete a paragraph, reread over the paragraph and ask yourself if it makes sense. Again, put yourself if the reader's shoes and ask yourself, "If I was new to this technology, or if I was learning about this concept, would this paragraph make sense? Would I understand it?" Perhaps there are terms or buzzwords used that have not been previously defined. Perhaps you had subconsciously "skipped over" important parts to understanding the concept you're trying to illustrate because you find these parts to be trivial. However, a reader learning the technology might not have a complete understanding or picture without these missing parts.

    At the end of high-level sections from the outline, be sure to summarize the material covered. Take a step back from the techno-jargon and reiterate in very simple English what the reader has just learned, and its application. Let the reader know where you'll take them next and how what they've just learned will play in. Explain in conversational English so a Luddite could understand.

This is just a smattering of little bits of advice that I use daily in my writing. If you are interested in strengthening your writing skills, I would encourage you to try adopting some (or all!) of these suggestions, and then, and most importantly, practice. Write articles for technological Web sites, or, if nothing else, create your own Web site and post them there. Share them on usenet, or online forums, and see what your readers say/ask. Do they have questions about certain things? Were some things unclear? Take this advice to heart and learn from it.


1 - Apologies for the cheesiness!
Filed under:
Two new Data Web Controls FAQs
10 July 03 11:19 PM | Scott Mitchell

I added two new FAQs to DataWebControls.com, FAQs that I've been wanting to create for quite a while now, since many folks new to creating editable DataGrids have these questions:

  1. Programmatically Accessing the Contents of a BoundColumn
  2. Programmatically Accessing the Contents of a TemplateColumn

That brings the number of ASP.NET Data Web Controls FAQs up to 18!

Filed under:
Ok, let's try something new
10 July 03 02:59 PM | Scott Mitchell

In my previous blog entry I shared ways with which I come up with ideas for articles. I have a new approach I'd like to try out, a more proactive one: I'd like to ask you what I should write about.

I have a couple of 2,000 word articles I need to get cracking on before too long for the MSDN Web site, and rather than use the old tried and true methods, I thought I'd see if there were any particular articles the few unfortunate souls who read my blog would care to hear about. So now is the time for the four of you to speak up! :-)

Seriously, if there are any facets of ASP.NET you'd like to see covered in more detail, or covered at all, or have been wondering about a particular feature of ASP.NET, or how one might accomplish a certain task with ASP.NET, please leave a comment, and I just may write an article based on your suggestion.

(I doubt I need any legalese here, but just to be safe: please realize that by sharing your idea for an article you are granting me permission to, at my discretion, use the idea for a future article for any publishing outlet I choose. Of course if I do use your article suggestion I will be certain to give you full credit in the article text as the originator of the idea for said article.)

Coming up with ideas
08 July 03 08:16 PM | Scott Mitchell

Technical writing is so much easier when you are told what to write about, as opposed to having to come up with an idea yourself. However, oftentimes this responsibility falls square on the shoulders of the author (as it should, usually). Such is always the case for editors of technical Web sites who place themselves in the precarious position that I have: namely, I have a weekly newsletter that has paid subscribers, and the newsletter contains fresh content. Translated this means that I need to come up with a new idea for an article and create an article based on that idea at least once a week. And by a week I really mean within two to three days, since I usually don't sit down to start the newsletter, which goes out on Wednesday morning, until Sunday or Monday. (Of course creating a newsletter once a week isn't nearly as hard as what I did my first six months running 4Guys - then I had a newsletter called WebDaily, which, as the name implies was sent out every freakin' day.)

One option is to merely offload the work to someone else. As any sane Web editor will tell you, it's a smart move to solicit other authors to write for your site. Of course, depending on the author, the job of editing the author's work can be exponentially more time-consuming than creating an article from scratch! In any event, over the years I've served as the 4Guys editor, I have received a number of potential author candidates who were excited about giving back to the community by writing for 4Guys, but were plumb out of ideas and wondered if I had any. As you can see, coming up with ideas can be tricky!

In my experience, I've found a number of tactics helpful for coming up with ideas. The fist tactic, which is the simplest and best, is to use real-world ideas. That is, you're working on a project, you hit a snag, bang your head against the wall for hours on end, and then finally come up with a neat work-around or solution. These types of things are great material for technical articles. However, events like this do not happen on a regular basis for me, especially since writing, consulting, and teaching are my full time job - that is, I'm not at a company developing all day.

Failing any real-world experiences, the next place to turn is online messageboards, email listservs, and newsgroups. I'll spend maybe half an hour digging through recent posts, trying to find some good questions that make me think, "Yes, answering this problem would make a great article." Those are nice too, because you can forward the article to the person who asked the original question, so it's like you're directly helping someone out. Positive karma and all. And, if you already spend significant time browsing through these resources, then oftentimes you know what the common questions and problems developers are asking and facing, and can bypass the actual searching through the resources.

If no online questions do the trick for me, I'll turn to existing articles on other resource Web sites. No, I'm not looking for ideas to copy, rather I'm looking for neat solutions that have potential to be enhanced, or explained in a different way. For example, I might find an article that's short on explanation and long in code on how to perform a cool task. This makes a great basis for an article. I can start off the article like, "I recently read so and so's article at such and such URL, where she described how to do this and that." And then I can delve into a more rigorous English explanation, show a different way to solve the problem, and do so using a different language (if the article was in C#, I'll show it in VB.NET, or vice-a-versa).

Finally, if all of these techniques fail, as a last resort I'll recycle material from a past book of mine or from the course material of a past class I taught. Mind you I don't just copy text from an old book, but I'll take an idea I discussed in a chapter in a previous book, and write a new article on that material. This is usually the quickest writing job on my side, but it sort of feels like cheating. Plus, it's more fun to come up with a new idea or concept or slant on an existing article/question, than to merely rehash old material.

All of these past approaches essentially take something that I've or someone else have worked on before, be it a real-world application, someone else's question in a newsgroup, or someone else's article, and adds explanation to provide a useful article. However, the ideal situation is to come up with fresh, new content. For example, when writing magazine articles or books, oftentimes I need to come up with "new" ideas, or new ways to explain the standard material. For example, I recently finished an article for Microsoft's online MSDN Web site. I was asked to write about ASP.NET and XML. Now, even though I had a braod topic, I still had to spend some time thinking on how to formulate the article - what examples would I use? What direction would I take the reader? How would each section segue into the next? I find that thinking about this stuff while driving, showering, lying in bed before falling asleep, or during any other low-key "downtime" is ideal.

Coming up with new ideas is not only difficult, I've found, but also time consuming, because they can involve significant development time. For example, for the MSDN article I decided to step the reader through creating an news aggregator Web application, seeing as how this touched upon many pertinent XML and ASP.NET topics, like accessing remote XML documents, displaying XML data on an ASP.NET Web page, and translating XML data with XSLT stylesheets. Once I decided to go with this approach, and mulled over the organization of the article, I still had one big task in front of me: writing the application itself! Granted, an online news aggregator isn't rocket science, but it took up a full day to create the application.

Coming up with new ideas is definitely the hardest approach, and rarely makes its way into the weekly articles I write for the Web site (seeing as I usually only have two to three days to create the Web site content due to the looming Wednesday deadline!). I try to save the new ideas for books and magazine articles, unless the new idea can be quickly converted into an article, but usually it takes some time to mull the idea over in my head for a while before I begin writing. Furthermore, working with new ideas usually requires more editing time during and after the writing process, and when you have two to three days to wrap everything up, oftentimes this is not sufficient for more involved new ideas, some of which may require significant development time before I can start writing.

To summarize, there are a number of venues I examine when trying to come up with ideas, from using inspiration from real-world problems I've encountered, to directly trying to help a person who has posed a question to the online community, to enhancing an existing article or tutorial, and, finally, to rehashing old content. Ideally, each week I'd have the time, energy, and interest to come up with new ideas and concepts to write about, but typically there isn't enough time in the day for this sort of thing.

Filed under:
The economics of writing a computer trade book...
03 July 03 08:37 PM | Scott Mitchell

If your dream is to become a rich man, don't write computer trade books.

The Basic Economics
There are three major variables involved in determining how much a book author will make with a particular book:

  1. Royalty percentage1,
  2. Number of copies sold, and
  3. The book's price2

1 - the royalty percentage is usually fixed per book, not per author. A sole author might receive, say, a 10% royalty rate, whereas a book with three authors, each author would receive only, say, a 3% royalty rate.

2 - The price used in the calculations is the price the publisher sells the book to the bookstore. This is typically half the cost of the retail price.

In simplest terms, the revenue grossed by a book for an author is:

Gross = RoyaltyRate * CopiesSold * BookPrice

Running the Numbers...
Let's examine some of the common figures for these three variables - royalty rate, copies sold, and book price.

  • Royalty Rate - This figure varies by publisher and by the author. O'Reilly does a standard 10% royalty, although they likely increase the royalty for more accomplished authors - I can hardly see Larry Wall getting only 10% to write Programming Perl, but who knows. More accomplished authors can expect a higher royalty, in the low teens. This rate can also vary by publisher. I had a colleague who was very accomplished in his field and was offered in the 15-20% range by assorted publishers.

  • Number of copies sold - This number varies most heavily on the book. Since there are soooooooo many computer trade books on the same subject, there are a number of books that have dismal sales. By dismal sales, I mean under 5,000 copies sold. For ASP.NET, if a book can break the 20,000 mark, you're doing good for yourself. If you break the 40,000 mark, you really wrote a great book that has really been well received.

    In my personal experience, the technical book market has been painfully soft over the past couple of years. This can be evidenced by Wrox's demise.

  • Book price - Again, keep in mind that the price used in the computation is the price the publisher sells the book to the bookstore. This is roughly half the price that you, Joe Sixpack, pay at the bookstore. With the declining sales, this figure has also come down slightly over the past couple of years. Boo.

So, let's say that you decide to write a computer trade book and you receive a 10% royalty. The book does fairly well, selling, say, 10,000 copies (not at all unrealistic, especially for a first-time author like yourself) at $29.95 per copy in the bookstore (which means the bookstore dropped, say, $14.00 per book). How much dough did you make? Well, let's find out:

Gross = RoyaltyRate * CopiesSold * BookPrice
Gross = 0.10 * 10,000 * 14.00 = $14,000.00

You made $14,000! Not bad for your first book. But... how long did it take you to write the book? And when, precisely, did you receive the $14,000?

The Book Writing Process and Payment Schedule
How long it takes to write a book depends on a number of factors, the most pertinent one being how much free time you have. This can be near zero if you have a regular full-time job and family. Other factors contributing to the duration it takes to write a book is the book's total page count, the author's writing speed/efficiency, and the author's knowledge of the material.

Technical books can range from 150 pages to 1,500 pages, but most, I'd say, are in the 400-800 range. The book writing process, for such lengthed books, usually takes, at minimum, three months and, at maximum, a year. (If you can output 400-800 pages in less than than three months time then clearly you are a very efficient professional writer! All five of my books took right around three months to write, and I consider myself to be a quick writer and throughout those times I've not had a "standard" nine-to-five job, leaving plenty of time for writing.)

So, returning to our fictional example, let's say that your book will be 700 pages long, and it takes you seven months of writing to get the first pass of the writing done. Sure, there will be another three to four months of techincal reviews, edits, and whatnot, but from the author's perspective, these months require much less work and energy than the intense writing period. So, 700 pages in seven months is 100 pages per month. Recall that we already determine that you will make $14,000 off the book, it's as if you are being paid $2,000 a month (since it took seven months to write), or $20 per page.

In case you were wondering, the payment of the $14,000 is spread out as follows: you will receive part of it as an advance during the writing process, typically anywhere from $5,000 to $15,000 dollars dolled out over the seven months of writing. Let's say your advance is a typical $10,000. The remainder of the money is distributed as the books sell. With technology changing so quickly, computer trade books have a very short shelf life, usually limited to two to three years at a maximum. For example, in early 2000 my first book, Teach Yourself ASP 3.0 in 21 Days, hit the bookstore shelves. Here it is, three and a half years later, and ASP 3.0 is like so passe. So, the remaining $4,000 or so that we determine the book will make will trickle in over the next two years.

Magazine Writing - A More Profitable Venue
Recall that books pay somewhere in the neighborhood of $20 per page. Magazine writing, on the other hand, comes in at a much higher dollar per page number. For example, many magazines like articles in the two to four thousand word range, which translates to five to ten book pages. For these two to four thousand words, though, magazines will pay between $500 to $2,500 dollars, depending on the magazine and author. Using the 10 page estimate, this comes down to $50 to $250 per page! Also, magazines are far less stressful to write since a magazine article can be crunched out in a few days to a week, rather than requiring several months.

While magazine writing is definitely more profitable, don't totally discount book writing. There's something cool about being able to stroll into a bookstore and see your book(s) on the shelf. Nothing makes a resume look better than having authored a book or two on the technology that you're being hired to work with. And book writing and book publishers are a great way to move into magazine article writing.

In a future posting I'll be sure to share ways to get started writing a book, from creating a proposal, to contacting prospective publishers.

Filed under:
Welcome to my Blog!
02 July 03 11:39 AM | Scott Mitchell

Ok, so I decided to jump onto the "blog bandwagon" and create my own blog. I am such a tool.

Anyway, the purpose of this blog is not so much to disseminate technical information - plenty of Web sites for that - but rather to discuss technical writing. As editor of a popular ASP/ASP.NET Web site, I have written literally hundreds of online articles, and have edited hundreds of articles from other writers. I have written, currently, five books on ASP/ASP.NET, and a slew of magazine articles. With this experience and exposure on 4Guys, I get asked quite frequently a multitude of questions on technical writing, from how to get started to how to write more useful, concise, and interesting content. The point of this blog, then, is to share this information and experience I've gathered over the past four years.

Filed under:
More Posts

Archives

My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.