While lately I’ve been endlessly streaming the latest news with horrified fascination, this morning my calendar unexpectedly popped up a reminder set over a year ago… Today is the fifteenth anniversary of my big-league blogging debut on the Internet Explorer Team’s blog.

My first post there, “A HTTP Detective Story” remains one of my favorites. Sadly, its topic feels all too familiar: a website took a dependency upon a browser quirk, the Referer and User-Agent headers were critical elements of the repro, and I used Fiddler to root-cause the problem. I’ve learned (and shared) so much more about these topics over the last fifteen years, and I appreciate the readers who’ve followed me from the IEBlog to IEInternals (237 posts) to Telerik’s Fiddler blog (41 posts) to my book, to this, my newest blog, TextSlashPlain (189 posts and counting!).

Here’s to learning and sharing for the next 15 years!

With gratitude,


Sadly, you’re unlikely to get wealthy by writing a book. You should definitely write one anyway.

My Background

People I respect suggest you shouldn’t write (or buy) books on specific technologies, going so far as to say that writing a book was on their top-10 lists of life regrets. Top-10… whoa!

As a consequence, when I was approached to write a book about Internet Explorer in 2009, I turned it down. “No one reads books anymore,” I asserted to the Vice President of the Internet Explorer team. At the time, I was sitting about 6 feet from my bookshelf full of technical books that I’d been buying over the last decade, including a few I’d purchased in the last month.

My counter-factual stance continued for the next few years, even as I served as a technical reviewer for five books on web development and performance. Then, in 2011, as I started pondering the sale of Fiddler, I met some product managers at the proposed acquirer and watched them use Fiddler for a few minutes. I was appalled—these guys had been looking at Fiddler for six months, and seemed to have settled on the most cumbersome and complicated ways to get anything accomplished. It wasn’t really their fault—Fiddler was incredibly feature rich, and I couldn’t fault them for not reading the manual—there wasn’t one. I felt a moral obligation, whether I sold Fiddler or not, to at least write down how to use it.

At the time, my wife was training to run marathons and I had quite a bit of free time in the mornings. Not knowing any better, I did what I assumed most writers do—I took my laptop to the coffee shop in the mornings and started writing. My resolve was aided by two crutches—

  1. I was happy to describe Fiddler, feature-by-feature, from top to bottom, left to right (Hemmingway, this wasn’t), and
  2. I decided that even if I abandoned the project without finishing a proper book, I could just save the results to a PDF, title it “Fiddler-Manual.pdf” and upload it to the Fiddler website.

I’ll cover the mechanics of actual writing in a future post (surprisingly straightforward, but I have some advice that may save you some time), but for now it suffices to say that after nine months of work a few times a week, I had a book.

My Investment

Writing the first edition took about 110 hours authoring, 20 hours of editing, and 30 hours of designing the cover, fixing formatting, and futzing with the printer/publisher webapp. I spent about $50 on draft copies, $40 or so on the cover photo, $20 on the fiddlerbook.com domain name registration, and about $650 for coffee and pastries consumed while writing. From September 2011 to June 2012, I periodically took a “snapshot” of my progress by printing the work:

Fiddler draft copies

Writing took about three months longer than my prediction:

Notebook with dates crossed out

… in part because as I wrote, I discovered what I’ve come to call Book-Driven Development (covered in the next section).

I was proud of the final product, but skeptical that it would earn back even what I spent on coffee.

So, Why Write?

First, it’s something parents and other folks can tangibly hold and appreciate. It’s probably the only way my grandmother will ever have any idea what the heck a “Fiddler Web Debugger” is and why someone might use one.

Second, it’s tangible. Many people have contributed to Fiddler over the years, and I can inscribe a paperback copy and send it to them as a “Thank you.” When the book was finished, I bought a dozen copies and dropped them off in the offices of colleagues who’d made contributions (in the form of bug reports or suggestions) over the years. One of the proudest moments of my life was when I got an email from Mark Russinovich thanking me for the signed copy and noting that it would nicely complement the ebook he’d already bought.

Third, writing a book makes you think very very hard about what you’re writing about, and with a different mindset. The Fiddler book took quite a bit longer to write because I made hundreds of improvements to Fiddler while I was writing the book, because I was writing the book. Almost every time I thought of something interesting to explain, I began to write about it, then realized that whatever it was shouldn’t have been so complicated in the first place. I’d then go fix Fiddler itself to avoid the problem. In other cases, explicitly writing out everything you can do with Fiddler made me recognize some important (and in hindsight, obvious) gaps, and go implement those features. I started calling this process Book-Driven Development and Fiddler was dramatically improved over the authoring of the book. Having said that, this also made writing the book take quite a bit longer—I’d write three or four pages, realize that the feature in question shouldn’t be so complicated, and go implement a checkbox or a button that would do everything the user needed without explanation. Then I’d have to go delete those three or four pages and replace it with “To do <X>, just push the <X> button.

Fourth, I got to choose what to write about. Fiddler is insanely powerful, but after watching people “in the field” use it, it was plain that most of its functionality is completely unknown to the vast majority of users. While some users watch the videos and read the blog posts, it was clear that there are some number of folks for which a complete book with an end-to-end explanation of the tool is the best way to learn it.

Fifth, it gives you an appreciation for other authors that you may never get otherwise. Marathon runners probably have more respect for other marathon runners than the general public ever will, simply because they know how grueling it is to run 26.2 in a way that someone who hasn’t never will. I think the same is probably true for book-writers.

So, in summary:

  1. It’s tangible.
  2. You can gift it to contributors.
  3. You’re forced to think like a new user.
  4. You can drive the direction of usage.
  5. You learn to appreciate authors.
  6. Self-publishing significantly changes your book’s financial prospects.

Money Matters

One of the challenges with almost any profit-making endeavor is that folks are so coy about the numbers involved. Inspired by John Resig’s post on Programming Book profits, I’m going to share my numbers here. My goal isn’t to brag—I think these are solid numbers, not runaway success numbers, but I want to show why “You’ll never make any money selling a book” is simply untrue.

Having read a bunch of posts like Jeff Atwood’s and Resig’s, I realized that going the traditional publisher route was a bad deal for both the reader and for me– the Fiddler book would have been ~$30 and I’d see maybe two or three dollars of that. Self-publishing is a better deal for the reader (lower prices) and it’s a better deal for me (I get about $6 and $8 respectively). While a traditional publisher would have probably netted me an advance of a few thousand bucks (more than I expected to make) I frankly prefer the “honesty” of being solely responsible for my book’s sales, and the often happy feeling I get when I (obsessively?) check sales stats and find that I sold a handful more copies overnight.

The first edition of Debugging with Fiddler was released in June 2012. The book was self-published on Lulu for the ebook (a PDF) and via CreateSpace (paperback) which was mostly sold on Amazon. The Lulu ebook was sold for a flat $10, while Amazon set the price for the paperback, usually at a small discount off the nominal $18.99 cover price.

Here are the sales figures for the ebook on Lulu:


The paperback sold slightly better, with 2713 English copies sold; the CreateSpace report below includes the 319 copies sold (so far) of the Second Edition:

3032 copies sold

Beyond the sales of my book, I also agreed to let the book be translated to Korean, Chinese, and Japanese by three local publishers. Each publisher agreed to an advance of about $1500, as well as three or four copies of the translated paperback. Of these, only one publisher (O’Reilly Japan) sends follow-up royalty statements; the book sold approximately 1400 copies in Japanese, and their advance was followed by a royalty check of $1450 in February of 2014.

On March 5th of 2015, I released the Second Edition update, revised to describe the changes in Fiddler over the last three years. This too proved far more successful than I’d ever dreamed. The $14.99 PDF (usually “on sale” for $9.99) took the lion’s share of sales with 840 copies sold, vs. 319 copies of the revised paperback. While the paperback stayed at CreateSpace, I moved to GumRoad for the new ebook for reasons I’ll describe in a future post.

$7453 royalties

So, how much did I earn? A bit more than $53318 or so thus far– the Euro/GBP exchange rates make the math a bit tricky. I spent about 200 hours of solid work on the First and Second Editions, so this works out to a bit over $250 per hour. Pretty amazing, for a project that yielded so many non-financial rewards!

Results Will Vary

It’s worth mentioning that my sales numbers are almost certainly much higher than they would’ve been “naturally”, but for one critical factor— as the developer of Fiddler, I was in a position to advertise the book both on the Fiddler website and in the Fiddler application itself. Exposed to millions of Fiddler users, this exposure was obviously invaluable and not, alas, something available to most writers.

It’s also the case that as the tool’s author, I benefit from credibility and name recognition (people expect that I’ll know what I’m writing about). As the primary source, I also have the luxury of writing more quickly since I didn’t need to do much research (subject to the “Book driven development” caveats earlier).

My (long overdue) next book project, Blue Badge, is a memoir of my time working at Microsoft, and it won’t benefit from the incredible exposure I had for Debugging with Fiddler. I’m intrigued to see how it sells.


If you’re an aspiring author, or simply interested in book publishing, I hope you found this post useful!


This is a list of books I’ve read recently, with a Twitter-fitting review for each. I’ll update it periodically.


The Martian – I greatly enjoyed this book; I was planning to try to get it some attention, but just before I tweeted, I learned it’s about to be a major motion picture. Oops. :-)

Wool – Great dystopian sci-fi. The writer is the closest thing the self-publishing industry has to an evangelist, and he’s awesome at it.

Ready Player One: A Novel – a light, fun read; I loved it.

Mr. Penumbra’s 24-Hour Bookstore – Fun and odd.

Seveneves: A Novel – I love Stephenson’s earlier work, and some of his later work (e.g. Reamde). This one was a mixed bag—it managed to reduce the magic of spaceflight to a boring set of “delta-v”s. On the other hand, every time I considered putting it down, there was a twist that pulled me back in.


Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications – If you want an accurate, up-to-date book on TLS, this is the one to buy.

Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety – A terrifying and great book; if you don’t know why you should still be afraid of nuclear weapons, you need to read this book.

Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon – A great book; reads like a techno-thriller… but it’s non-fiction.

An Astronaut’s Guide to Life on Earth: What Going to Space Taught Me About Ingenuity, Determination, and Being Prepared for Anything – Canadian astronaut Chris Hadfield’s memoir. I wanted to be an astronaut as a kid and this reawoke that interest to a surprising degree. But it also clearly pointed out the trade-offs (37 out of 52 weeks a year on the road) that I couldn’t imagine making with a family.

How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life – Cartoonist Scott Adams’ memoir and suggestions for success in life; it’s similar in ways to Hadfield’s memoir in being a mix of stories and advice. There were parts of this I really disliked, but there were some great parts too. The best was the repeated advice that goals are for suckers, systems are for winners — similar to Hadfield’s advice, this points out that life is more about the journey than the destination, and if you ever make it about the destination, you’re going to be in very bad shape after you realize you’ve reached it and can’t imagine what to do next.

On Writing Stephen King writes about writing — how he does it and how to do it well. It’s awesome.

Stories I Only Tell My Friends – Rob Lowe’s memoir; I had low expectations, but this book crushed them– it was funny, surprisingly interesting and very well-written.

There’s a writer living in my head, and he’s a genius.

Or so he tries to convince me, as his prose flows freely day in and out, filling most idle moments– while I’m showering, driving, dining, taking out the trash, or performing any of the other mundane tasks of daily life. His prose is brilliant– his points always well aligned, his recall of long-ago events and facts uncannily perfect, and his agility in seamlessly transitioning from one topic to the next is above reproach. He never needs spell-check or a thesaurus, and he never struggles to find the right way to approach the topic. His efforts are frequently interrupted by periods of basking in the glorious reception he imagines for his easy labors, and is certain that untold rewards are sure to follow.

Unfortunately, this genius is a huge jerk.

As soon as a spare moment is found in which hands can be placed upon a keyboard or a notepad, he’s either nowhere to be found, or not “in the mood” to rehash old topics that were perfectly formed in the ether… to commit such brilliance using a device so banal as a keyboard is an insult, it seems, and he won’t dare to be part of such an endeavor.

Over the years, I’ve found that the only way to write is to just type, painfully, whatever drivel comes to mind, scaffolding up the roughest of approximations of what he might say, providing nary a distraction to amuse him. With false start after false start, rewrite after rewrite, I suffer until he comes out, clucks his tongue at my pathetic efforts, and begins to guide my fingers on the keyboard. He bridles at the annoyance of checking facts (rolling his eyes in distain each time an inaccuracy is found—“the piece would be better if I was right!” he argues) and groans each time my feeble mind grapples with a word choice.

When a throwaway tweet gets 300 times the pickup of a hard-scribed blog post, he groans and rants at the inanity of the mortal world.

But what alternative is there?