As it turns out, I’m not the first person to ever write a book!

When I sit down to start writing a new app, I don’t agonize over what files to create and what to call them. I don’t start at an empty project in my editor and wonder where to start.

No, I click File | New Project in a menu, or I run a console command, and shazam, I have a skeleton of a project. Maybe I have a website with a few sample pages, or a mobile app with a single screen, or a console app with a Main method already defined.

I use pre-built templates or scaffolding to give me a leg up and show me where to put the main pieces of my application, so I spend less time worrying about the structure of my application and can get right down to business writing the code that’ll make it do something unique.

So why, on my last two book projects, have I pretended that no one has ever written a technical book before?

A lot of the stress and angst I’ve experienced while working on my Sublime Text books has been caused by one question: Where should this piece go?

And that’s caused by my writing process, which until now has gone something like this:

  • Experiment with Sublime Text and scan the web to learn about a group of features, taking notes in the process.
  • Open Scrivener and paste in my pages and pages of notes.
  • Review my notes several times, looking for logical connections among the fragments of information and shuffling them around until they’re more or less grouped.
  • Name the groups. Tada! Now I have an “outline.”
  • Start writing in the spaces between my fragments, stitching them together into something that resembles cohesion.

My process, in other words, is very bottom-up. I collect disparate pieces of information and then stare at them, hoping for order to emerge. This works, to an extent—the brain excels at making connections like that.

But good grief is it a painful process. Every scrap of information is treated equally, and it’s difficult to know what I can safely omit. So I convince myself that I have to include everything, and the project bloats out of control. I contort my writing to shove in minor details that the reader probably won’t care about and doesn’t need to worry about. And of course I always end up with a pile of leftover pieces that don’t seem to fit anywhere—but I have to put them somewhere because I wrote them down when I was taking notes!—and I end up scurrying around and poking them into cracks and crevices (known technically as insets and sidebars).

I’m acting like no one has ever written a technical book before. Like there are no tried-and-true structures that hundreds of authors and editors have developed and fine-tuned through decades of tears and red ink. It’s downright silly when I think about it like that.

I never would have realized all of this if I hadn’t decided to force myself to complete a detailed outline for my current book project. Normally I start off with good intentions about creating an outline, but as soon as the discomfort sets in, I decide to wing it and just fall back to the process I described above.

But this time, I’ve vowed, I’m not going to let myself skimp on the outline. I’m going to push through the discomfort and map out the entire book in detail.

I was squirming in my chair, shuffling a few scant bullet points around aimlessly, and it hit me: What if I could start with a preexisting structure and just plug in what I’ve learned from my research?

And as it turns out, there are well established structures. I spent 30 minutes talking to my friend, John Sonmez, who cranks out an insane amount of technical content every month, and every one of his courses follows a well-defined formula. I grabbed a few well-reviewed books from Amazon, and wouldn’t you know it, they follow a similar structure.

After I made this “discovery,” my angst over how to organize my book disappeared, and I cracked open Scrivener and started cranking out my outline. All of the information I’d collected started organizing itself into this predefined structure. It was almost effortless—I was just putting the pieces where they clearly belonged. And when I occasionally got stuck, I’d refer to my examples until I found an example of how another author had solved a similar problem.

Through this process, I’ve relearned an important lesson: Don’t allow yourself to get stuck trying to solve a difficult problem in a vacuum. Look for a ready-made solution so you can keep moving.

Related posts:

  1. How I’m going to write four books in 12 months If you search DuckDuckGo for “how to write a book,” you might be tempted to just give up on the whole idea. The top-ranking results are littered with words and phrases like “torture,” “horrible experience,” “didn’t make any money.” The conventional wisdom is that writing books is an arduous process...
  2. Why I’m writing a book no one will buy I have no idea if anyone will ever buy the book I’m working on right now. This is entirely my own doing. And you know what? I’m fine with that. There’s a right way and a wrong way to find book topics. The right way involves picking an audience, then...
  3. Write a book or build my audience—which should I do first? Subscriber Claudio is a programmer who wants to make a name for himself by building a thriving blog and email list, and writing a book. He’s bouncing around in his own head, though, and can’t get traction: I run a personal blog since 2008. I haven’t posted consistently, there were...
  4. The dangers of faking your outline Writer’s block isn’t something I usually struggle with, but I ran smack into a wall yesterday. It was pretty unexpected, and working around it taught me a valuable lesson about outlining. I’d cranked through my daily practice writing session in record time, and when I cracked open Scrivener to work...