Writing a Book with Packt

This summer and fall I had the opportunity to write "Refactoring with C#", a technical book on C# development, through Packt Publishing.

When I considered doing this project in the spring there wasn't much out there on what it's like to be an author with Packt, so I thought I'd share my experience writing the book for those considering it in the future. Please note that this is focused just on the writing process. I'm deliberately not covering the proposal and outlining phases as I plan to write a separate article on that topic.

Also, you may be coming into this article with a negative opinion of Packt Publishing. I read a lot of technical books, including many from Packt, and can attest that they hit a slump awhile ago with quality issues in their published books. I have to say that my experience with Packt was almost entirely positive - provided that you make the assumption that you as the author own the quality level for your own book. We'll talk more about this as we go on.

Drafting Chapters

The drafting process for the book starts a week or two after the book's proposal and outline are approved and the contract is signed.

Packt provides a Word template that they expect you to follow. This template uses special format markers that match Packt's styles and formatting. These styles include special coloration to help communicate the style during the editing process and result in your markup looking very colorful:

Because Packt wants you to use these styles, it means that you can't just use Ctrl + B to bold or Ctrl + I to italicize. I was surprised how much this slowed me down, but it did slow me down until I found a workaround for it.

I eventually edited Packt's template to include keyboard shortcuts for the formats I used frequently. I then took those complex keyboard shortcuts and created buttons for them in my Stream Deck setup:

I then mounted the Stream Deck next to my monitor so it was always in reach and in my peripheral vision as I was writing:

This effectively "gamified" formatting and helped me format things as I went without needing to page through different Word settings to find the style I was looking for.

Before I found this productivity improvement I wrote my chapters in markdown and then ported them over to Word. I stopped doing this after the first few chapters once I realized that adapting the format from markdown to Packt's styles took a longer than expected amount of time.

The Writing Process

When I built the schedule for writing, I assumed that I'd be writing two or three days a week for two or three hours a session. I figured that if I focused on writing the code for a chapter first then the content for the chapter would flow easily from there.

This assumption largely turned out to be true, but the biggest thing that changed from my plans to the actual writing process was that I found I couldn't just write 2 or 3 nights a week. I found that the book crept into all of my creative processes and things flowed better if I worked on it at least 5 days each week.

This change had the positive effect that I was able to keep momentum more easily from night to night, but it also heightened the negative effects of writing a book as well. I found myself missing working on other learning projects or just playing around with interesting technologies. I also largely stopped playing games during this time, though I still found ways of resting and re-energizing myself.

Usually I was able to get a first draft of a chapter done every 10 days or so. The book topic was one that I was well-acquainted and didn't really require research, so when I was happy with the direction of a chapter's code, the rest of the chapter flowed easily around it.

The exception to this would be three of the early chapters in the book. I knew I had 3 large chapters focused on various refactoring techniques, but what made sense to me during the outline phase of the book didn't make as much sense when I went to write the book. I found myself constantly moving things between these three chapters. I eventually wound up moving and renaming the chapters themselves. The content I intended to put into the book made it, but the sequence and flow of that content changed.

Because I saw the content flowing between these three chapters, I told Packt I'd be delivering the three chapters together, instead of one-at-a-time as each chapter was initially drafted. This wound up being one of my smartest decisions in writing the book as it gave me greater freedom in making these chapters as good as I could. Also, to Packt's credit, they were very accommodating on this need and the resulting structural changes to the book versus what I had planned and what we agreed on during the outline phase.

The other thing I noticed about writing was that my estimations of page length for chapters and the actual page length were rarely very close. Images and code listings took up a lot of page height, resulting in higher page counts. Additionally, many of my chapters were built to be step-by-step tutorials with very explicit steps which added to the page count. I believe this was the right decision for early chapters, but it did increase the overall page count.

Adapting working code to code listings in a book is a non-trivial skill. You have a very limited width per line to work with and you also need to keep the overall length of the listings down so it can fit on a page and content can flow freely. Choosing short variable and method names that are clear to the reader is a skill. I also found myself adopting a different curly brace style than I normally program with in order to make an economical use of page space.

Editing Chapters

Once you complete a chapter, you can email the Word document to your editor team or upload it to their author portal (which is what I did).

From there, Packt usually got first draft feedback with edits back to me between 3 and 10 business days from when I gave them the first draft. These revisions often came in waves with me getting several from the editor within a day or two. This can add significantly to your stress level to have edits waiting for you while you're trying to form a later chapter. However, when it came down to actually responding to edits, it was far easier than authoring the chapter to begin with.

Much of the editing feedback I got was on consistency of use of Packt's styles, consistent casing, and working on improving transitions between sections and chapters of the book. There was also some very valuable feedback in there on run-on sentences, overused words, and unnecessary adverbs.

The entire Packt team that I worked with were scattered throughout India. This meant that my US English writing style didn't always translate to Packt's editorial team. This helped me identify phrases that work in programming settings in America but may not translate well to international readers.

On working with an international team, I actually really enjoyed it. I live in US Eastern and wrote each night from 9:30 PM to midnight. Every Sunday night I'd give Packt a weekly report with plans for the next week. When I needed to I'd email them more frequently, but usually at the end of a night. I'd then start winding down for the night, and I'd often have a reply before I went to bed.

Often I'd wake up with messages from Packt in my inbox, which gave me something to think about as I started my day. I found this was a very effective way to work with my editor and it was often a treat for me to wake up and see what progress had been made on the book overnight.

Technical Review

Once a chapter is approved from editorial review it gets sent on to the technical reviewers. In my case I recommended a number of my friends from the Ohio technical community as technical reviewers for the book. This decision was one of the best decisions I made for the book's overall quality because these people were stellar and I knew they were stellar going into the project. I knew my technical reviewers understood the topic and had great perspectives on .NET development.

Knowing my technical reviewers knew what they were talking about and were invested in making the book as good as it could be made them incredible allies in writing the book. They flagged things that were unclear, technologies I could mention, and occasionally things that didn't work for them or places where I wasn't fully correct.

The technical revisions section is also the last place you can freely make significant edits, so I used this in many cases to add in extra polish and make the chapter more cohesive with other chapters. The technical reviewer feedback was very helpful in this regard and I frequently found myself removing, adding, and modifying content in response to the suggestions from my reviewers.

I don't know what happened in Packt's books of poorer quality a half decade ago, but I imagine one of the key things they were missing was world class technical reviewers like I had through Calvin, Brad, Sam, Matthew, and Steve.

Final Proofs

Once you pass off the book to Packt and all chapters hit technical review, the book enters the final phases.

During this phase Packt has copy editors and proofreaders look for issues in the chapters. If they have questions, your editor will get in touch and ask for clarifications on areas of confusion.

Once this process is complete, the chapter gets laid out by a typesetter and you'll get a PDF of the chapter in its potential final state.

I read this PDF on my tablet and marked it up in digital ink when I found issues. You will definitely find issues during this phase. The issues may be readability, inconsistencies, casing or formatting, or potentially things related to the typesetting process.

I also found a few places where the copy editors made incorrect assumptions about the intent of a sentence or section and wound up accidentally inverting my meaning. This is why I say you have to own the quality of your book. Spend time proofreading it and be explicit in the changes you want to see based on what you found.

What I wish was Different

As I wrap up this article on writing a book with Packt, let's talk about what I wish was different.

I loved the process of writing the book and would gladly do so again. However, there were a few things that I would want to change about the process.

First, Packt doesn't have any sort of early access program like Manning or PragProg offer with their titles. Under an early access program, readers can read your content while it is still in development. This system allows you to get early feedback on a book, detect issues early, and start to make sales and gain a following while the book is still in development.

In fact, I didn't have a page that I could link anyone towards on the book until the book had been finalized and its Amazon pre-release page and Packt's page for the book came out. This meant that I was speaking at conferences and user groups and doing other activities that would make it easy to market the book, but there was no action I could ask anyone to take if they were interested in the book. I estimate that I talked to about half a thousand people over the months I was writing the book, and there was nothing anyone could do but follow me for future updates if they had interest.

The next major thing I'd change would be having a process that could generate chapter PDFs early on in the development cycle. Every time a chapter draft gets submitted, I'd like a PDF to be created for ease of reviewing and reading. This would make it easier to read the overall flow of the content instead of getting fixated on Packt's formatting markers.

This is also an idea I found in LeanPub's systems. I'm currently using markdown to write and self-publish a small book on Computer Vision on Azure through LeanPub. One of the things I love about this process is that I can write content in markdown and version it in git, then push it to my cloud repository and LeanPub automatically generates a PDF of the entire book for me to preview.

Having git-based version control for content would also have made it easier to catch content issues like copy edits that inverted my meaning.

Ultimately, I'm very glad I wrote this book and I'm glad I went with Packt. I plan to write with Packt again in the future, though I am curious about workflows at other publishers and have even explored some ideas with other publishers for content in the new year.

Stay tuned for more articles on writing Refactoring with C# as we approach the book's release on November 24th.