独家优惠奖金 100% 高达 1 BTC + 180 免费旋转

Writing a technical book with Manning in 2020

Two months ago I published Modern Fortran: Building Efficient Parallel Applications with Manning Publications. It was a long journey (3 years!) and here I describe my experience: The writing process, tools I used, working with Manning staff, the economics of writing a technical book, and challenges. Though the title of this article mentions the year 2020, my experience reflects the period from mid-2017 to late-2020. A few things may have changed in the meantime, but most of it is relevant. If you’re considering writing a technical book or have just started doing so, this article may help you.

Writing a technical book was the last thing on my mind. In May 2017, I got an email from Mike Stephens, the Acquisitions Editor (AE) from Manning. (An acquisition editor finds prospective authors and works out the idea and scope of the book). Mike wrote something like:

“Sure thing”, I said. In that moment I didn’t believe I was cut out for the job, but the idea excited me so I closed my eyes and took a leap of faith.

Here’s the timeline of key events:

Mike and I got on a call and brainstormed ideas. I wanted to write a Fortran cookbook for intermediate-to-advanced programmers. Mike geared the book toward beginners, teaching the language from scratch and by example. What we ended up with is a Fortran beginners book that teaches the essentials (but not everything) through practical, hands-on examples.

The next step was to write a book proposal, which consists of a questionnaire and a sample Table Of Contents (TOC). These are then reviewed by the AE who provides feedback to revise both the questionnaire and the TOC. I made one round of edits to both the TOC and the questionnaire, and sent them to Manning, who sent the proposal to reviewers. In my case, there were six: Four scientists, an HPC sysadmin, and a retired compiler developer. Three of them I knew of by name and their work. To my pleasant surprise, the reviews were strongly encouraging. More exciting to me, in the midst of reviewer response emails, there was an email from Manning with the contract and ISBN number for Fortran in Action. The news came while I was visiting the NASA Jet Propulsion Laboratory as an invited speaker. I let my loved ones know and went to celebrate with spicy lamb vindaloo in the highest rated Indian restaurant in Pasadena.

Looking back, the original TOC from the proposal looks nothing like the book we ended up making.

Manning issued a draft of the contract with what I think are their default terms that they send to prospective authors. They asked me to review and sign. We had a few back and forths negotiating the details, and we were then ready to sign. Here are the key terms that we agreed on:

The contract also stated delivery deadlines and target number of pages, words, figures, and code listings. There were a dozen other legalese items in the contract that aren’t interesting enough to mention here. I will touch on this topic again when I discuss the economics of writing.

When we started the work, Manning set me up with:

Once the first MEAP (Manning Early Access Program) version is out, you get:

There’s also a Slack workspace for Manning authors which I didn’t use.

Most of the time I worked on a chapter at a time. The workflow for each was:

In the beginning I asked Mike what software should I use for writing. He said “Use anything you want!”. Then I wrote the proposal in LaTeX and asked if it’s okay to use it for writing the book. Short answer: No, use Asciidoc or Microsoft Word — these are the tools that Manning’s production team works with. So Asciidoc it was. I hadn’t used it until this point, but it was an easy choice for me.

I‘m not a big fan of Asciidoc but I made it work for me. It’s more powerful than Markdown but simpler to use than LaTeX. Writing math requires an external tool, and even when you jump through the hoops to set it up, the result is uglier than any MathJax-enabled Markdown or LaTeX math rendering. This turned out not to be a big deal because Manning strongly discouraged using math in my book. Nevertheless, where I used math I ended up just rendering it in LaTeX and turning it into a figure:

In practice, I’d write Asciidoc files using Atom or Vim (interchangeably), then compile them using Asciidoctor into a pdf for preview. In Atom I used the asciidoc-preview plugin, which does exactly what it sounds like.

Most figures — diagrams and illustrations — in the book I made using LibreOffice Draw. This software is simple and a joy to use. Here’s one of my favorite figures from the book which illustrates how Fortran 2018 events work:

A few others I made with Python and matplotlib in xkcd mode. I used this to illustrate a math concept but still wanted that hand-drawn look. Here’s an example:

Before this book I had only made figures for academic papers which is a whole different business. Making pretty and clear diagrams and illustrations was something I had to learn. They were universally praised by early readers and reviewers alike, which encouraged me to make them even better.

Manning provided a dedicated online forum for readers to post questions and suggestions about the book, while it’s being written. This was great — to an extent, my readers helped improve the book by providing feedback like “there’s a typo here” or “explain this a little more”. The forum itself was an old-fashioned, Web 1.0 kind of forum in the spirit of phpBB. This is not a negative — it was clean, simple to use, and it worked.

At the time that I started writing, I had transitioned from on-site to fully remote work for my day job. This gave me additional 2 hours every work-day — about 30-minute commute each way, plus about an hour for prepping (bag, laptop, clothes, lunch, etc.) and winding down when I came home. I could then add 1–2 hours of book work each day without taking away from any day-job work or personal time. This was a blessing.

Early on I had committed to work on the book for one hour, and no more, every day. I’d wake up, stretch, have a glass of water, and start writing. Doing it every day and first thing in the morning helped me develop the habit so that writing eventually became its own raison d’être — I don’t write because I have to but because that’s what I do. I also made an effort to not write more than one hour. This has two important effects:

Of course, this was my commitment but not the reality — I often did not follow through. Both writing daily and setting a time limit are easier said than done. There were many days when I didn’t write in the morning before the day-job work started, so I’d then write at the end of the day. Everybody’s different and I know that many authors work well at night, but this wasn’t for me. There were many days when I didn’t write at all — during intensive 3-day science meetings, business trips, or on vacation. Once I’d slip with my daily writing habit, it was difficult to get back into it. There were also many days when I worked on it for several hours, usually on weekends, to meet a chapter deadline. The reality for me was different from my original commitment, but that’s real life. What matters is that you set the intention and do your best.

So, what did my writing habits actually look like? Here are some stats:

On most days I either didn’t work or I worked the one hour as intended. I had only one day when I worked 9 hours, and 7 days that I worked 8 hours. All of these were to meet a deadline and I didn’t enjoy them one bit. Here’s the full distribution:

The purpose of my hour-per-day commitment was to maintain consistency. To see how I did, I looked at my writing streaks — periods of time when I wrote daily:

My longest streak was 39 days! I was impressed when I saw this number. However, streaks longer than a few days were extremely rare. The streaks were 3.46±4.18 days-long on average, with a median value of only 2 days. Writing consistently is hard!

Finally, in my writing log I also kept track of what I was working on. Here’s the breakdown:

The main takeaway from this figure is that not most of the time goes into writing, as I had previously assumed. I spent a significant chunk of time on editing (31.1%) and programming (15.1%). Of course, the programming part is specific to programming books, although you’re likely to spend a similar amount on time on some other kind of research for non-technical books. The time spent on marketing (3.3%) was relatively small, although it didn’t feel like it when I was doing it. Marketing consisted of posting on social media, writing blog posts, and emailing people who helped give away e-book copies at events.

I faced a few significant challenges while working on this book.

I already mentioned staying consistent with the daily writing habit: Writing is easy; starting to write is hard. On many days I had to simply force myself to sit down and type through the first 5–10 minutes of resistance.

Early on I struggled coming up with concrete examples. Coming from academic science where everything is taught, described, or explained in abstract terms, I was at a loss coming up with specific, concrete scenarios to engage the readers. When I thought of examples, they either seemed too simple to be interesting, or they were too complex to explain well. The editors were patient with me and taught me a lot about this during our coaching calls. In the end, I’m quite happy with the examples that I used and the seem readers enjoy them as well.

When the editor feedback on Chapter 6 draft came back, it suggested rewriting the chapter from scratch. This was a low point in my writing process and it took me about a month to get back on my feet and start writing again. The problem was that this chapter was meant to teach derived types (classes). Instead, it taught derived types, and neural nets, and parallel reduction operations. I bit more than I could chew.

Manning has a comprehensive and diligent review process. Editors review every chapter as it’s written and provide feedback and suggestions for edits.

There are also three external reviews, one at each third of the book completed. For these, Manning sends out the book to about a dozen or so technically literate reviewers who are not affiliated with Manning, and who may or may not be familiar with the topic of the book. The reviews are comprehensive — reviewers are asked to assess the quality of the explanations, figures, topics covered, writing and programming style, and more. Many reviewers provided detailed suggestions beyond just answering the questions. They’re also asked to give the book, in its current state, an “Amazon” star rating. This was fun — in each review cycle I could see how my average Amazon star rating changed, which was telling me if I was on the right track.

The reviewers also report their self-assessed expertise with the topic (Fortran), on a scale from 1 to 10. Here’s what the distribution of that looks like across all reviews:

I don’t know if Manning selects reviewers with diverse levels of expertise, or it just happens so. In my case, the distribution is bimodal, with a group of reviewers not too familiar with Fortran, and another who self-reported as advanced Fortran users.

One of the metrics for success was the Amazon ratings from each review. Reading through the reviews I was just hoping for no 1s and 2s, please! 3s I consider okay, and if most ratings were 4s I’d be happy.

First two reviews scored almost equally, 3.82 on average. I was discouraged by the second round of reviews — we didn’t seem to have moved the needle. Then Manning re-did the second review, with suspicion that the original pool of reviewers was not representative enough for the topic at hand. They sent the same draft for another review, but this time with considerably more reviewers being familiar with Fortran. The feedback this time was significantly more positive, with the average rating of 4.21. Finally, we were moving in the right direction! By the time the final review feedback came, the average reviewer score was 4.53. Perhaps not suprising, but reviewers who were more familiar with Fortran also thought that the book was higher quality.

As for the feedback, the reviews were somewhat polarized. About half of the reviewers thought that the book was too easy, the other half that it was too hard. Half wanted more math and physics, the other half wanted less physics and more everyday examples. Do you see the pattern? The feedback that was consistent across most reviews was that there were enough many examples, they were interesting, and that the illustrations were high quality and engaging. This was encouraging enough for me to press on.

I’ve interacted with about a dozen of Manning staff, from editors and marketers to designers and web developers. What stood out to me the most was how every single Manning person was highly professional and owning their work. Sure, occasionally people made minor mistakes or miscommunicated, but any problem that came up was owned and fixed promptly and without resistance.

Overall, I can’t recommend enough working with a great publisher — and Manning certainly is one — and having all the support that you need as a first-time author. Mike (AE) told me early on: “We don’t expect you to be a great writer when you start. You focus on your topic that you’re an expert in. We focus on making great books. We’ll make sure that your writing is great in the end.”

You’ll spend a lot of time writing your book. Financial rewards are rarely large, and for most technical books they are symbolic.

Royalties for technical books tend to be low — about 10%. From my research, I found this figure to be common and expected. With Manning it was no different.

Although I did ask for a higher royalty rate for ebook sales (I got that idea from someone on Hacker News), Manning refused, simply saying “Sorry, we don’t do that”. I had to try.

As I wrote earlier, the advance was $5000, half of it paid when the first third of the book is finished, the other half when the book is done. The advance is the amount in royalties that the author receives ahead of time. If the royalties don’t make up for the advance, you keep it. Once they exceed the advance amount, you begin to receive royalty paychecks every quarter.

Manning offers to pay their authors via PayPal or direct deposit. For convenience, I initially chose PayPal. What I didn’t realize at the time was that I’d incur a 3% merchant fee for receiving the payment there. For a $2500 payment, this is ~$80. I wasn’t happy about this but realized that it was my mistake and moved on. When the time came for the second advance payment, I asked Manning to use direct deposit instead and explained why I wasn’t happy getting paid via PayPal. Manning were so gracious and caring that they added the amount to cover the merchant fee from two years before. It’s a small gesture, but it convinced again that Manning truly cares for their authors.

Manning reported the sales during the MEAP on seemingly irregular intervals. Between May 2018 and January 2020, I received 7 such reports. They details the basic progress metrics — chapters complete, chapters reviewed, number of pages so far, and similar — but also the number of copies sold so far and in the last 30 days. I plotted them here:

The spike in the Spring of 2018 corresponds to the burst of sales when the book was first released in the early access program. Then the sales steadied down at the ~25 copies / month. By January 2020, there were 833 copies sold and that was the last report that I received. Assuming that the linear trend continues, we’ve surpassed 1000 copies sold sometime in the summer. There should be another burst in sales around the publication time but I haven’t received the sales report yet.

These numbers may seem discouraging at first. How my book is doing says nothing about how your book will do. It depends a lot on the topic. Fortran is nowadays a niche topic with a small target audience so we didn’t expect that it’d be selling like books on Rust or React would. But Fortran is an extremely mature technology and it’s not going away any time soon. So I expect this book to sell slowly and for a long time. However, I do hope that it sells well enough to warrant a second edition, perhaps around the time when the next Fortran standard (202x) is published.

When my MEAP was first released (March 2018), Manning also set me up with an affiliate program account. It gives you a unique ID to include in the URL for your or any other Manning book. When a click on my link leads to a book purchase, I get 8% of the sale price.

I didn’t at any point actively promote Manning books as an affiliate. I simply placed this URL on my personal book website and on the book’s GitHub page, and forgot about it. So far my affiliate account has generated:

It’s not much but considering that I barely did any work about it, it’s nice to get. Divided by 30 months that I worked on the book, this comes out at about $12 / month from commissions on average. Let’s go for ice cream, my treat.

Here are my takeaways and suggestions for anybody embarking on this journey:

I hope this helps. Last but not least, here’s the link to my book:

If you’re interested in buying the book but want to get a taste for it first, download Chapters 2–4 as a free ebook here:

Add a comment

What is your view?

Send

Related posts:

A Winter Awed Filled Break

My husband and I enjoyed our date night together at Starved Rock National Park in Illinois. We got a later start than we wanted. It was dark by the time we arrived, but the lodge was full of laughter…

Guide to Designing High Converting Graphics for Social Media

This is a step-by-step guide to creating eye-catching images for social media that drive engagement and leads — all without a designer. You are aware of the power of visual content. Yes, social media…

On Human Spirit

We are struggling to protect our planet, our environment, and our species. The beacon that will guide us through the darkness is the light of the human spirit.