Posted on
by

Tim Ferriss is the author of The 4-Hour Work Week, The 4-Hour Body, and the upcoming 4-Hour Chef.

I am personally thankful to Tim Ferriss, because due to the 4-Hour Work Week, I was able to establish goals for what I wanted to be doing that was personally relevant to me. Instead of saying that someday I’d launch a business, or someday I’d write a book, I did those things. Someday doesn’t come, unless you make it come. And the 4-Hour Work Week helped me get more efficient, both in my job and in my personal work, so that I could then find the time to pursue those dreams.

Without the 4-Hour Work Week, I don’t think I would have been able to write or publish my technothriller Avogadro Corp: The Singularity Is Closer Than It Appears.

Thanks to the 4-Hour Body, I’ve lost weight (20 pounds), I’m eating healthier, and I’ve reduced my health risk of cardiovascular disease. Not only does this feel good for me, but it’s important for my family too. I have three small kids, and they’d be really sad if their dad died.

The brilliant Gene Kim said, Tim Ferriss has “helped a generation escape shackles & achieve their dreams.”

And he keeps on doing it. Tim Ferriss, through his Opening the Kimono conference taught authors and publishers how to achieve publication success. In the 4-Hour Chef, Tim aims to teach people not only how to cook, but how to master any set of skills.

If you haven’t read a Tim Ferriss book yet, go get one. It’ll will be worth your while, and it might just change your life.

Posted on
by

When I’m not writing science fiction novels, I work on web apps for a largish company*. This week was pretty darn exciting: we learned on Monday afternoon that we needed to scale up to a peak volume of 10,000 simultaneous visitors by Thursday morning at 5:30am.

This post will be about what we did, what we learned, and what worked.

A little background: our stack is nginx, Ruby on Rails, and mysql. The web app is a custom travel guide. The user comes into our app and either imports a TripIt itinerary, or selects a destination and enters their travel details. They can expressed preferences in dozens of different categories (think about rating cuisine types of restaurants, categories of attractions, etc.). They can preview their travel guide live, in the browser, and order a high quality paperback version.

Our site was in beta, and we’ve been getting a few hundred visitors a day. At 2pm on Monday we learned that we would be featured on a very popular TV show on Thursday morning (9:30am EST), and based on their previous experiences, we could expect anywhere from 20,000 to 150,000 unique visitors that day, with a peak load of 10,000 simultaneous visitors. This would be a 100x to 1,000x increase in the number of unique visitors that we would normally serve. We estimated that our peak volume would be 10,000 visitors at once, which would create a load of ~40,000 page requests per minute (rpm).

What we had going for us:

  • We were already running on Amazon Web Services (AWS), using EC2 behind a load balancer.
  • We already had auto-scale rules in place to detect when when CPU load exceeded a certain percentage on our app servers, and to double the number of EC2 instances we had.
  • We had reliable process for deploying (although this became a constraint later).
  • A month before we had spent a week optimizing performance of our app, and we had already cut  page load time by 30%, largely by reducing database calls.

On Monday we got JMeter installed on a few computers. With JMeter you can write a script that mimics a typical customer visit. In our case, we wrote a script that loaded the home page, selected a destination, went through the preferences, and went to check out. Although we didn’t post to any pages (which we would have liked to, if we had more time), a number of database artifacts did get created as the simulated user went through the user interface. (This is important later.)

After some experimentation, we decided that we couldn’t run more than 125 threads on a single JMeter instance. So if we wanted to simulate truly high loads, we needed to run JMeter on several computers. We also needed to make sure not to saturate any part of our local network. At a minimum, we made sure we didn’t have all the machines going through the same router. We also VPNed into an entirely different site, and ran another client from a geographically distant location.

We quickly learned that:

  • we needed to change our initial auto-scale group from two servers to four.
  • we needed to reduce our CPU load threshold from 80% to 50%.
  • we needed to reduce the time we sustained that load from 5 minutes to 1 minute.
After making these changes, and letting the app servers scale to 16 servers, we saw that we were now DB bound. The DB server would quickly go to 100% load. We increased to the maximum AWS DB size (extra extra large, with extra CPUs and memory) but we still swamped the DB server. We watched the JMeter tests run, sending the average response times into the 30 second territory. We knew we were sunk if we didn’t solve this problem. It was mid-day Tuesday.
I said “we knew we were sunk”, but to be honest, this actually took some convincing. Some members of the team felt like any changes so close to the big day would be too risky to make. We could introduce a bug. But a 100% correct application experience that will definitely get buried under load will result in delivering no pages to anyone. That’s 100% risk. After a few hours, we had everyone convinced that we had to solve the scalability issues.
We briefly explored several different large scale changes we could have made, but ultimately judged to be too risky:
  • duplicating our entire stack, and using DynDNS or Amazon’s Route 53 to route between them. Because we didn’t have users accounts or other shared data, we could have done this in theory. If we had, we would later have needed to synchronize a bunch of databases through some scripts to collect all the customer data together. If we had a week or an Ops expert, we probably would have done this.
  • offloading part of the DB load by creating a read-only replica, and shunting some of the database calls to certain mostly-static data (e.g. list of destinations and attractions at those destinations) to the read-only database. We didn’t do this mostly because we didn’t know how we’d point some database queries at one db server, and others at a different db server.
  • using memcache or other mechanisms to hit only memory instead of database: this too would have been extensive code changes. Given the short timeframe, it felt too risky.
The action we did decide to take:
  • We had a few easily identified DB queries that ran with every page request, that loaded the same data each time. We rewrote the code to cache these in memory in global variables that stayed resident between calls. So they would get loaded once when the servers rebooted, and never again.
Around this time, which was Wednesday morning, we started to get smarter about how we used JMeter. Instead of slamming the servers with many hundreds of simultaneous threads from many clients and watching request times spiral around of control, we instead spun up threads slowly, let the servers stabilize, counted our total throughput in requests-per-second, and checked CPU load at that level, then increased the threads, and kept rechecking. We grabbed a flipchart, and started recording data where everyone could see it. Our goal was to determine the maximum RPM we could sustain without increasing response times.
As the day went on, we incrementally added code changes to cache some database requests, as well as other late-breaking requests we needed before we were live on Thursday. This is where our deployment process started to break down.
We have the following environments: local machines, dev, demo, staging, production. Normally, we have a test script that runs (takes about 40 minutes) before pushing to dev. The deployment script takes 15-30 minutes (80% of which is spent waiting for git clone. Why???) And we have to repeat that process to move closer and closer to production.
The only environment that is a mirror of production is staging. If we had a code optimization we needed to performance test, it would take hours to deploy the change to staging. Conversely, we can (and did) log into the staging servers and apply the changes manually (ssh into server, vi to edit files, reboot mongrel), but we would need to repeat across four servers, bring down the auto-scale servers, rebuild the auto-scale AMI, then bring up the auto-scale servers. Even the short-cut process took 20 to 30 minutes.

We did this several times, and carefully keeping track of our data, we noticed that we were going in the wrong direction. We were able to sustain 15 requests per second (900 rpm), and the number kept get lower as the day went on. Now the astute database administrators who are reading this will chuckle, knowing exactly what is causing this. But we don’t have a dedicated DBA on the team, and my DB skills are somewhat rusty.

We already had New Relic installed. I have always loved New Relic since I used it several years ago when I developed a Facebook app. It’s a performance monitoring solution for Rails and other web app environments. I had really only used it as a development tool, as it lets you see where your app is spending it’s time.

It’s also intended for production monitoring, and what I didn’t know up until that point is that if we paid for the professional plan, it would identify slow-running page requests and database queries, and provide quite a lot of detail about exactly what had executed.

So, desperate to get more data, we upgraded to the New Relic Pro plan. Instantly (ok, within 60 seconds), we had a wealth of data about exactly what DB requests were slow and where our app was spending it’s time.

One DB query was taking 95% of all of our DB time. As soon as I saw that, and I remembered that our performance was getting worse during the day, it all snapped into place, and I realized that we had to have an unindexed field we were querying on. Because the JMeter tests were creating entries in the database tables, and because they had been running for hours, we had hundreds of thousands of rows in the database, so we were doing entire table scans.

I checked the DB schema.rb file, as saw that someone had incorrectly created a multi-column index. (In general, I would say to avoid multi-column indexes unless you know specifically that you need one.) In a multiple column index, if you specify columns A, B, and C in a query, you can use it to query against A, A and B, or A and B and C. But the columns are order dependent, and you cannot leave out column A.

That’s exactly what had happened in our case. So I quickly created a migration to create the index we needed, we ran the migration on our server, let the server have five minutes to build the index, and then we reran the tests. We scaled to 120 requests per second (7,200 rpm), and the DB load was only 16%.

This was Wednesday afternoon, about 3pm. At this point we figured the DB server could handle the load from about 36,000 page requests per minute. We were bumping up against the app server CPU load again.

At some point during the day we had maxed out the number of EC2 instances we could get. We had another team doing scalability testing that day, and we were hitting some upper limit. We killed unnecessary running AMIs, we asked everyone else to stop testing, and we requested an increase in our upper limit via AWS, then went to our account rep and asked them to escalate the request.

By the time we left late Wednesday night, we felt confident we could handle the load on Thursday morning.

Thursday came, and we all had Google analytics, New Relic, and our backdoor interfaces covering all screens. Because it was all happening at 5:30am PST, we were spread across hotel rooms and homes. We were using Campfire for real-time chat.

The first load came at 5:38am, and the spike happened quickly: from 0 visitors we went to over a thousand visitors in just a minute.  Our page response times stayed rocky steady at 500ms, and we never experienced any delays in serving customer pages.

We had a pricing bug come up, and had to hot patch the servers and reboot them while under load (one at a time, of course), and still were able to keep serving up pages. Our peak load was well under the limits we had load tested, but was well over what we could have sustained on Monday afternoon prior to the changes we made. So the two and a half days of grueling effort paid off.

Lessons learned:

  • Had we paid for the Pro plan for New Relic earlier, we probably would have saved ourselves a lot of effort, but either way, I do believe New Relic saved our butts: if we hadn’t gotten the data we needed on Wednesday afternoon, we would not have survived Thursday morning.
  • Load testing needs to be done regularly, not just when you are expecting a big event. At any point someone might make a database change, forget an index, or introduce some other weird performance anomaly that isn’t spotted until we have the system under load.
  • There needed to be a relatively safe, automated way to deliver expedited deployments to staging and production for times when you must shortcut the regular process. That shouldn’t be dependent on one person using vi to edit files and not making any mistakes.
  • We couldn’t have been scaling app instances and database servers so quickly if we weren’t using a cloud service.
  • It really helped to have the team all in one place for this. Normally we’re distributed, and that works fine when it’s not crisis mode, but I wouldn’t have wanted to do this and be 1,000 miles away.

*As usual, I’m speaking as and for myself, even when I’m writing about my day job, not my employer.

Posted on
by

(Originally written for IndiesUnlimited as guest post.)



My first book, Avogadro Corp: The Singularity Is Closer Than It Appears, came out in December. It was a great book launch, but after the holidays passed, as you might expect, sales slowed. 
The feedback I was receiving told me the book was good. One friend said she had nightmares after reading it (it’s a techno-thriller). Another reader sought out the coffee shop where several scenes were set and took photos of himself with the book. A local tech blog in Portland posted a very positive review. Amazon reviews are overwhelmingly positive.
So the real question was how to let more people know about Avogadro Corp.
I decided to experiment with Facebook ads. if you haven’t used Facebook ads before, here’s a quick overview:
  • Go to http://facebook.com/ads or click on the advertising link at the bottom of the main Facebook page.
  • Ads consist of an image, a title, a small amount of text, and a destination link.
  • You pay per click, so it only costs you when someone clicks on the advertisement. Ads can be targeted by age, sex, country, region, and interests. 
  • You can set spending limits so you’re in control of how much you spend. You can conduct a useful ad experiment with as little as twenty dollars.
I knew my own writing would appeal to fans of Charles Stross, Cory Doctorow, and William Gibson. I write about similar subjects in a similar style. So I ran a series of Facebook ads specifically targeting fans of each of those authors. 
Here’s a typical ad:

Facebook’s advertising console tells me how much I’m paying per click. For example, in the last seven days, I had 96 clicks on my Charles Stross targeted ad, and paid $0.34 per click.
The advertising console also tells me the CTR (click through rate). For my author-specific ads, the CTR has been 0.2% and higher. That tells me that out of every 1,000 times the ad has been shown, it’s been clicked on 2 times. That might not sound very high, but compared to loosely targeted ads (e.g. people who like read, or people who live in a certain geography), it’s anywhere from 10 to 100 times higher than those more general ads.
The URL for a Facebook ad can be any page on the Internet or even your Facebook author page. I use avogadrocorp.com which is the homepage for my book. I’m specifically trying to drive sales of the book, as opposed to getting people to follow me, or any other objective. You could also send people directly to an Amazon.com page for your book, but I prefer that the URL should in the ad also reflect my book’s brand.
I use statcounter.com to keep track of hits to avogadrocorp.com. I can see who referred visitors to my site, and the overwhelming majority are from Facebook, so I know it’s the ads accounting for most of the traffic.
The tricky part is determining exactly how many books you sell as a result of those visits. The standard industry term for this is conversion. By checking my site traffic through statcounter.com and my book sales through the Kindle Direct Publishing reports daily, over time I’ve found that about my book sales tend to be 10 to 15% of my website traffic. I can’t be sure that all of those sales are generated from my website, but by watching the correlation, I know that most of them are.
Here’s where we have to do a little math.
  1. Since 15% of my website visitors buy a book, then I need to send about 7 (100 / 15 = 7) visitors to my site for each book I want to sell.
  2. Since it costs me $0.20 each time someone clicks on my advertisement, then it costs me $1.40 ($0.20 * 7) in advertising to sell one book.
  3. I normally make about $3.00 on a book, so after advertising expenses, I still clear $1.60 per book.
As you can see the key variables to pay attention to are: cost per click, conversation rate, and profit per book.
If it costs you less in advertising than you make per book: congratulations! You can conduct a successful targeted advertising campaign. Now you can choose to spend more on ads to sell more books, always earning more than you spend.
If your conversion rate is low, you may need to better target your ads to find people who would be interested in the book, or you may need to redesign your website to make buying the book easier, more obvious, or more compelling.

Good luck!

Posted on
by

Recently a friend mentioned that they were interested in a writing critique group, and I was inspired to share my experience with them. I’m in two writing critique groups, both focused on novel length work.

Formulation

One group is small (three people, including me), and we meet every two weeks, and everyone is expected to bring a chapter. We haven’t missed a day yet in the three month’s we’ve been meeting, although we did drop from five members to three. The three that are left are very committed and all very much oriented on getting published.

The other group is larger (five people), and we’ve been meeting a year. We review two chapters every time we meet, and our intention is to meet twice a month, although we probably average 1.5 times per month. About half the group seems very serious about being published.

I think it’s great to have people at or slightly above your own writing level (this is paradoxal, as it’s clear not possible to achieve this for all members). But clearly you can benefit from strong writers who can offer the most accurate and constructive feedback. I also think it’s beneficial to have people who have a similar level of commitment to publishing. If there’s too much of a mismatch, it can be discouraging to people who aren’t producing as much, and not constructive enough to the people who are producing a lot.

I think critique groups benefit from writers of different genre, because you learn more about different ways to do stuff, from revealing character to handling dialogue, etc.

Approach

I think it’s good to be able to share something at least every two weeks. Less often than that, and you can’t really get an appreciable amount of feedback from the group.

That being said, one thing that makes critique groups work well is trying to learn as much as possible from critiquing itself, so that you improve as a writer by the act of critiquing. For whatever reason, I find that I’m more likely to research things like grammer, dialogue, and structure when I’m reading someone else’s work. (I suspect it’s because if I am going to say something critical, I want to be sure that what I’m saying is correct.)

My writer teacher says that it’s easier for the new writer or non-writer to know when something is wrong than to know what is wrong, let alone how to fix it. It can be tempting to suggest how to fix things to others, but as a beginning writer, I’d hate to think I’m giving bad advice. So I try to stick first and foremost to identifying where there are problems, especially in my written comments. (“I got lost here.” “This sentence confuses me.” “I’m surprised the character is acting this way.” “Something is not right.”) Then I might verbally expand upon that during the actual meeting.

We have a rule in my smaller group that you must send material to be critiqued at least three days ahead of time. I think this works well to ensure that everything is given it’s proper amount of time and attention.

I critique either on paper or electronically. Then we discuss. In one group we allot half an hour, and the other group, forty-five minutes. I suspect it could be done in twenty, if you pay close attention to the clock. After thirty minutes, it’s usually diminishing returns.

Process

We use this process during the actual meeting (this is somewhat hypothetical, as my two groups use slightly different processes):

  • Author can provide an intro, specific what feedback specifically they are looking for.
  • Author is then silent, doesn’t contribute anything, but can ask clarifying questions.
  • Someone summarizes the action of the chapter. We check to see if everyone agrees.
  • Someone (or all) identify what they see as the “center” of the chapter.
  • Go around the circle twice, each time a person talks about something they liked about the chapter, usually reading a line or two aloud.
  • Go through issues, from large to progressively smaller.
    • When people are nit-picking grammer, you know the structure and plot is essentially fine.
  • As we near end of time, author is allowed back in to comment on what they heard, ask other questions.
Meeting
Finding a place to meet can be tricky. In one group we’ve been using a teahouse that’s open until 10pm. In the other group, we use a coffeehouse. We’ve tried meeting at people’s houses, and I think this is fine, as long as the process of meeting doesn’t distract from the business of critiquing.
We usually use the first twenty minutes or so for settling in, comparing what we’ve been up to, or sharing things we’ve learned about writing or publishing.
We’ve discussed meeting in bars, but they are frequently noisier than coffee/tea houses, and may lack wireless. A hipflask poured into a teacup works just fine. 🙂
Critique Gone Bad
I’ve heard people discuss nightmare scenarios where their critique group is highly negative and/or some of the people who attend don’t contribute anything but simply criticize everyone else’s writing. I feel very fortunate to have never encountered these types of scenarios. If this is your experience, I strongly suggest finding a new critique group.
If you are starting a new critique group or looking for one, I hope this is helpful.
Will

Posted on
by

Ah, commas before “and”, you are my nemesis! But now I think I understand you better.

There’s the whole debate on Oxford/serial commas, which I will skip. Suffice it to say it’s the situation where you are using commas to delineate a list. Some say to put the comma before the “and”, some don’t, but either way, it’s a style thing and as long as you are consistent, it’s OK to do either.

But the problem I had when what to do when we’re not talking about a serial list.

From Get It Write I found this description:

The second situation occurs when “and” is being used to coordinate two independent clauses. An independent clause—also known as a main clause—is a group of words that has a subject and a verb and can stand alone as a sentence. In the following example, the independent clauses are in brackets:
  • [Miguel took piano lessons for sixteen years], and [today he is an accomplished performer].
The use of the comma would also apply when any of the seven coordinating conjunctions (and, but, or, nor, for, so, yet) join two independent clauses.
Notice in the next example that we do not use a comma before “and” because it does not join two independent clauses but merely joins two verbs:
  • Miguel took piano lessons for sixteen years and today is an accomplished performer.
Here we have only one independent clause—two verbs (“took” and “is”) but one subject (“Miguel”).

Posted on
by

I was recently asked, “How much editing should a writer do themselves?” It’s always hard to answer any question with a “should” in it, because the answer is different for everyone. We also need to know what the goal is? To send the work to an agent? Or to self-publish?

I’ll describe what I do when writing novels.

  1. I write my first draft. For each book I’ve written (I’m wrapping up my third), my first draft has become much better. 
  2. Then I make a first editing pass on screen. I’m looking for a bunch of different things, including:
    1. obvious typos and grammer mistakes
    2. places where I did too much telling and not enough showing (one of my chronic issues)
    3. obvious continuity errors: I changed a characters name, or their occupation, or where some characters were, etc.
  3. Individual chapters are shared with my critique group after my first pass. On average, my critique group sees about a third of my chapters for any given book. I fix any issues the critique group identifies, which can be about clarity, character motivation, excessive exposition, etc.
  4. Then I print the whole thing out, marking up the pages with corrections to small errors and identifying bigger issues to address. The things I tend to notice on the printed page:
    1. More typos and grammer errors
    2. Repeated use of words
    3. Continuity errors. 
    4. Flow of the story.
  5. Then I let it sit for at least a month, and work on other writing.
  6. Then I reread the whole thing again, primarily focusing on bigger story issues and more places where I need to show instead of tell. I’m also addressing plot issues here, character motivation and development, etc.
  7. Somewhere around here, I pass it around to my beta readers. They are a half a dozen people who read it and give me feedback. I correct issues they identify. These are different than my first readers: I have two or three people I give it to very early on, just for encouragement. They do give me some feedback, which I welcome, but I’m not dependent on. By the way, unless your mom has some special credentials as a writer or teacher, consider your mother a first reader, not a critical reader.  Of course she’s going to say it’s great. 🙂
  8. At this point, I’m comfortable sending it off to agents/publishers.
  9. If it’s not accepted by anyone, and I’m going to self-publish, then I keep going:
  10. I then send it to a copy editor, and correct issues they identify. I don’t have the budget for a professional copy editor, so I pay a friend who is a creative writing major with about six years of solid writing experience.
  11. Lastly I give it to a proofreader. Again, I don’t have the budget for a professional, so I pay a different friend, someone who is extremely detail oriented and focused with a good command of English.
I count seven editing passes:
  1. first editing pass on screen
  2. critique group feedback
  3. printed editing pass
  4. second printed editing pass after a month away
  5. beta reader feedback
  6. copy editor pass
  7. proofreader pass
That being said, it varies greatly on how polished the first draft is. My first novel went through ten editing passes before it even got to a critique group in step 2. A new writer may well have a dozen or more editing passes.

Posted on
by

I was recently asked “I’m writing my first draft of my novel, and I’m planning to self-publish in about six months. What should I be doing now that I might not know about?”

After some thought, I composed the following, which you may also find helpful:

After I finished my first draft, I several months editing. If this is your first novel, expect that you’ll be a better writer by the end, and you’ll probably want to go and rewrite quite a bit. I made ten complete passes through my book before I thought it was ready to be published.

Hire an editor and/or a proofreader if possible. I didn’t have the money for a professional, so I hired a creative writing major who had extensive writing experience and paid $10/hour. It took roughly 2 hours per 10,000 words.

If you can’t afford that, solicit friends for readers and divide them into two groups. Use half for an early draft, correct all the mistakes they find, and then use the other half to review the next draft. Be explicit to them about the kind of feedback you need: typos vs character feedback, etc.

Stop here: Are you interested in trying traditional publishing? If so, send it out to literary agents. Agents take simultaneous submissions, so you can send to 20 to 50 agents, and find out in a few weeks if anyone is interested. By comparison, publishers want non-simultaneous submissions, and take longer to respond, so sending to publishers takes years. After you’ve been rejected by everyone or if you decide to forego the pain of rejection, proceed. (I’m being flippant here, but personally I do solicit agents before self-publishing.)

You can work on your cover design in parallel. You should probably hire someone. Books are judged by their covers, and will be a major factor in whether people decide to buy it.

I made the choice to do a print version as well as an ebook version. Expect that the print version will take a lot of time if you choose to do it. Generating a 95% perfect epub version takes 2 to 3 hours. Generating a 95% perfect print version takes 2 to 3 WEEKS.

You will want to have a blog or website. Have a user-friendly URL to give people. Look at the websites of authors you like, and see what they are doing.

Have a user-friendly title for your book. I thought Avogadro Corp was a great name for my book because it gives great search results. Until the first time I tried to tell someone in a crowded room what the title of my book was. It turns out that it’s hard to verbally tell people “Avogadro Corp” and have them remember it. They usually think avocado. Not helpful. You want something that is meaningful, easy to remember, easy to spell, and will get good Google search results.

The very last page in your book after the story ends should be a call to action: If you enjoyed this book, take a minute to tell a friend or post an Amazon review.

When you launch, think about some of the following ways to promote your work:

  • Friends and family appeal: This is where you ask friends and family to buy your book via Facebook, email, and more. Even if you think that everyone is on Facebook, email more effective. It sits in front of people, in their inboxes, and causes far more action than just a Facebook post. Family and friends will be far more likely to buy print versions than ebooks. If you happen to launch near Christmas, remind people they can buy a book as a gift.
  • Facebook ads: If you are similar to other authors or your book will appeal to readers with a very specific interest, you may be able to reach them cost effectively through targeted Facebook advertisements. I wrote a blog post on targeted Facebook advertising: http://www.williamhertling.com/2012/01/promoting-books-with-targeted-facebook.html
  • Depending on where you live, particularly if you live in a smaller town, you may be able to get local media coverage. Send review copies to newspapers.
  • Send free review copies to friends who have blogs with any reasonable amount of traffic. (Buy them the kindle version or send them an epub or send them a print copy. They’ll almost always reciprocate with a blog post.)
  • Offer to do guest posts for other blogs.
  • Do book blog tours. (I don’t really get this one, so search it out.)

Any other ideas that you’d share with a new, unpublished writer who plans to self-publish?

William Hertling
http://www.williamhertling.com

Posted on
by

I happened to notice a writer ask the question of “Why do literary agents reject so many good submissions?”

The answer is simple mathPhoto credit:
http://www.flickr.com/photos/ktheory/21905281/

The answer is simple math.

A literary agent get anywhere from 25 to 100 submissions each and every day.

The agent themselves has to represent each work to publishers. Just as it takes the author time to send out their manuscript and cover letters, so too will it take the agent time to try to sell each work to publishers.

Maybe they can take on one or two new projects, if that, a week. If they get 200 submissions in a week, but they can only take two on to promote, that’s the simple answer: they must reject 198 submissions and they can accept two.

On a related note, a few words about pitches:

At first I was really bothered by this notion that I needed to be able to describe my book in less than twenty words to pitch it to an agent.

Then I heard an agent speak at Willamette Writers Con. The agent’s job is to take the book and pitch it to publishers. They have a minute or two on the phone with the publisher. They need to be able to describe it in just a few words, and then leave time for questions.

If the publisher wants it, they’ll need to pitch the book to distributors, book stores, and readers. If the publisher can’t put a twenty word blurb on the back that describes the book, then it won’t sell.

So if you, the author, can’t come up with a twenty word pitch, how can you expect the agent or the publisher to do it?

Once I realized all of that, my resistance to the short pitch evaporated.