I just received $5,947 in advance sales for my first technical book, even though it’s only 25% complete, and I’m self-publishing it. The book is called Refactoring English, and it’s a guide for software developers to improve their writing.

In March, I ran a three-week pre-sale for the book on Kickstarter. The pre-sale raised $6,551 from 191 customers. After Kickstarter’s fees, I get $5,946.92, or 91% of the total.

Suppose you host your podcast on a platform like Libsyn or Podbean. What happens if you decide to switch podcast platforms? You already gave everyone a RSS URL that pointed to your old platform.

For example Libsyn gives your podcast an RSS URL like this:

• https://feeds.libsyn.com/12345/rss

When you submitted your podcast to Apple Podcasts and shared your RSS URL with your listeners, you pointed them directly to your podcast platform.

Highlights

• My book’s pre-sale succeeded (just barely).
• I wrote a bunch of blog posts, and I was bad at predicting their performance.
• Now, I need to pick a markup language for writing my book.

Goal grades

At the start of each month, I declare what I’d like to accomplish. Here’s how I did against those goals:

Reach my $5k Kickstarter goal for Refactoring English.

• Result: The Kickstarter reached $6,701 from 196 backers.
• Grade: A+

The Kickstarter did better than I expected, making a last-minute comeback.

For the past few months, I’ve been working on a book called Refactoring English: Effective Writing for Software Developers.

I didn’t want to spend a year writing the book only to find out that nobody wanted to buy it, so at the beginning of March, I ran a one-month pre-sale on Kickstarter. I structured the project so that if I didn’t hit $5k in pre-orders, the project would be canceled, and I’d walk away with nothing.

Six years ago, David Thompson wrote a popular blog post called “My favourite Git commit” celebrating a whimsically detailed commit message his co-worker wrote. I enjoyed the post at the time and have sent it to several teammates as a model for good commit messages.

I recently revisited Thompson’s article as I was creating my own guide to writing useful commit messages. When pressed to explain what made Thompson’s post such an effective example, I was surprised to find that I couldn’t. It was fun to read as an outside observer, but I couldn’t justify it as a model of good software engineering.