What it’s like to write a book

Earlier this year, I published my new book, From Markup to Markdown, about how we’ve used computers for writing. It explores several milestones in using computers to write, including nroff, LaTeX, HTML, and DITA.

I loved writing the book. This was actually my second book with Springer/Apress; my first book with them was Technical Writing for Developers. And yes, I am already planning to write another book!

For the National Day on Writing, I wanted to share my process in writing the book. Here are a few highlights about what it’s like to write a book:

How would you describe the experience of writing your book? Was it easier or harder than expected?

I’d already written Technical Writing for Developers for Apress, so fortunately I already knew what to expect when writing From Markup to Markdown.

I love that the editors at Apress are so easy to work with, and they have a process that helps you as an author. You start with a book proposal. This proposal is a really in-depth look at what the book will be about, and what you might write about in each chapter, with a sample table of contents.

Going through that proposal process gave me an opportunity to be intentional about what I would write in the book. By the time I submitted the proposal, I had a very good idea about how the book would progress or flow from chapter to chapter, and what content I would provide in each chapter.

From there, my process to write the book was basically following the “road map” I’d provided in my proposal.

What was your schedule like when you wrote your book? Can you describe your writing process?

From Markup to Markdown has a lot of examples in it, so I would start each chapter by working out examples that I wanted to include.

For example, when writing about DITA, I first created a sample project that modern technical writers would be familiar with: creating a “catalog” of products, such as you might give to the Sales team. Then I expanded that project to reuse content to create different “install guides,” and then updating it again to create “user manuals.” I worked out all of that before I started writing about it.

For the chapters where I provide source code, I had a harder task. I wanted to show how it works by writing code, but always keeping in mind that this is not a book about programming. Every example had to be something that anyone could understand. To do that, I usually wrote several versions of each program, so I could show a very simple version, then add a little bit to it so it can do a little more, and so on. Each version of the program was just a little more than the version before it. And that takes more effort on my part, but it makes the sample code much easier to follow if you don’t know programming.

Once I had the examples and the source code, I could start writing the chapter. Doing that work up front made the writing easier.

Most technical authors write their books alongside work/life responsibilities. How did you find the time to complete your book?

I teach technical writing at a university, and I do some consulting on the side. That gave me a lot of flexibility to write a book. But you have to be intentional about finding time to write. It can’t be something that you just fit in between other things.

I write best in the mornings, so I set aside time on my calendar (when I wasn’t teaching) to just write. Get up, have breakfast, make coffee, and sit down at the computer to write the book. I’d try to stay focused on writing until around lunchtime, which gave me several hours every day to work on the book. You can get a lot done in that time, if you can avoid interruptions.

How did you get your started on your career path?

I’ve had a very interesting career path, and had a lot of different roles. My undergraduate degree was physics, with a minor in mathematics. After graduation, I had planned to do research—probably solid state physics, based on an interesting internship I’d had one summer with a research facility.

I’ll skip over the details, but the last internship I had before graduation was doing programming for a small, local company. I guess I did good work for them, because they reached out to me when I graduated and offered me a job, managing the Unix systems.

I spent much of my career in IT, working my way up to become a chief information officer in higher education, and then government.

I always enjoyed writing, and I wrote articles on the side for Linux Journal, Opensource.com, Linux Magazine, and other places. Most of these were technical “how-to” articles about open source applications, Linux, FreeDOS, the command line, and programming. I liked writing so much that I earned my MS degree in technical writing, even though it didn’t have anything to do with my role as CIO.

After I started consulting, a position happened to open up at the university where I had earned my MS. I advised graduate students in the technical writing program, and taught a few classes about technical writing. Later, I transitioned to a full-time instructor role.

That varied background really was a strength in writing the book, because I’d used so many writing systems, in each phase of my undergraduate and professional career. So I got to share that experience in the book.

Did you have writer’s block while working on your book? If so, how did you overcome it?

It happened, life can get in the way sometimes. For me, there was a brief moment when I needed to take a step back so I could refocus. After a bit of time, I found I was ready to jump back into the book.

I’m glad my editor supported me through that. I emailed my editor when I realized I was having trouble writing the book. I let him know what was going on, what I’d already written, and what was left. I also gave my best estimate for how much time I thought I would need to finish the book.

If an author has writer’s block, keep your editor in the loop. Just doing that, letting him know what was going on, was enough to take some of the pressure off me. Then I was able to get back to it.

Are there things you would do differently in terms of planning if you were to write another book?

Generally, I would try to have all my research ready to go and organized before I sat down to write.

I thought I’d researched everything before I started writing, but I realized as I went along that I’d missed some things. I needed more detail. I had to stop and go research a topic, then write some samples, so I could finish writing about it for the book.

What is your favorite book? Favorite author?

I have several favorites, it’s hard to pick just one!

My favorite fiction book that I’ve read in the last year has to be Project Hail Mary. I loved how Andy Weir was able to describe the math in a way that made sense for my physics background, yet kept it approachable for someone who didn’t have that interest. I loved the movie, too!

The non-fiction book I keep going back to is probably Unix: A History and a Memoir, self-published by Brian Kernighan. I’ve spoken with Brian several times, about the book and other things, and I love his first-person history of Bell Labs and the creation of Unix.

I used to drive a lot for a previous job, and I listened to a ton of audio-books and audio-stories. I still like to listen to Big Finish, who has the license to make Doctor Who audio-stories with the original cast. My go-to story that I’ve listened to countless times is the I, Davros 4-part series.

What’s your favorite font?

I’m happy to use whatever font is needed for the job, but my favorite font for personal projects is Palatino. The letters are well-formed, not too wide by not too narrow. Palatino 11-point is a great size for all kinds of documents, including books and articles. Palatino looks great in italic type too.

Based on this experience, would you ever write another book?

Definitely! I’ve actually started planning another book. I’m doing some research right now so I can write a proposal to bring back to Apress.

From Markup to Markdown is on sale now! Buy it from Springer/Apress, at Amazon, at Barnes & Noble, or wherever you buy books.

• Explore the history of technical writing in the age of the personal computer, from the 1960s to the present day
• Understand how key writing technologies and tools have evolved over time
• Full of practical code examples from RUNOFF, dot matrix printing, and Markdown