What I’ve learned while writing my first book

27 August 2018

This is the story of what I’ve learned so far whilst writing my first book, Camel Step-by-Step.

The blank canvas
The blank canvas

In March I started writing my first book. So far, the experience has been pretty enlightening, both on a personal and a technical level.

I feel like writing has helped me to learn quite a few things; although I never expected it when I first started the project.

I’m nearing the end of writing now, and I wanted to write this post to take stock, and document what I’ve learned so far.

How it began

To tell the complete story of what I’ve learned, I need to start at the beginning.

Creating a product is something I’ve wanted to do for a long time.

I’m a bit of an introvert, so writing a book was the first thing I thought of. Writing a book allows me to share knowledge and help other people (whilst at the same time hiding behind a computer screen ;-) ).

So, I started out in March. I picked a topic – the Java framework Apache Camel. I’ve already been blogging about it for a couple of years, so it seemed like a good choice. I threw together a rough book outline and a landing page, in one weekend.

Camel Step-by-Step landing page
Camel Step-by-Step landing page

The outline was mostly a guess, based on:

  • questions I get asked
  • things I wish I’d known when I first started
  • the topics of my most popular blog posts.

I stuck a pre-order now button at the bottom of the page, and made a start on writing the first draft.

The ‘difficult’ first book

I already acknowledged in a previous post that creating is hard.

But the first thing I discovered is that writing your first book is hard x 1,000.

I thought that in writing a technical book, it would just be a matter of documenting the things I know, and the book would easily come together.

But the truth is that writing is only half of the work - especially when writing a technical book.

There are many other things to think of - such as devising appropriate examples, writing sample code, and thinking about structure - these take up a lot of time.

Takeaway: Creating a book takes time.

Writing, slowly

Writing a book takes an unbelievable amount of time! Creating an app would have been quicker. 😂

Since March, I’ve built up the book content rather more slowly than I expected. Today, I just hit 25,000 words.

That means that over 5 months, I’ve averaged 5,000 words per month.

That’s not particularly fast, but I have improved somewhat since the beginning.

I’ve seen the biggest improvement most recently, as I’ve started making time to write in the mornings before work. I’m now making bigger strides than I have done previously.

I used to read blog posts from people claiming that they can write thousands of words in a day. I believed them for a while. Now I don’t really.

Takeaway: Writing is slow. That’s it.

Nobody tells you where to stop (the ever-growing quiche)

When you’re writing a non-fiction book, how do you know where to stop? I could write about my topic for months and months… and still not be finished.

I created an outline of the book, and I published a landing page before I even started writing. Yet I’m still adding chapters to the book which I didn’t expect I would be writing. Why is that?

I see the process of writing a technical book as a giant quiche:

The quiche of writing a technical book
The quiche of writing a technical book

At the edges of the quiche are the most advanced and complicated topics that I want to write about. In the centre is the core knowledge - the basics that need to be explained before the advanced stuff can be understood.

The smaller the quiche, the simpler the topics. But as I write about more complicated topics, the size of the quiche grows.

At some point, I have to draw a line at how deep I want to go into the topic, because the quiche will get too big for the dish (and making the filling in the middle will take ages).

Basically: the more advanced topics I write about, the more explanations (and writing) is needed. And the more time it takes.

Takeaway: It’s difficult to know where to stop when you’re writing a technical book. You need to somehow find the stop line. And stop there.

Every day I’m learning

The most enjoyable part of writing a book has been learning every day.

Although I’ve worked with Apache Camel for over 4 years, there’s still a ton I don’t know. (There’s also a ton I don’t know about Java, either. I work in a relatively small area of the language.)

You know nothing, Jon Snow (from Game of Thrones)
Whimsical Game of Thrones reference

It’s frustrating to realise what I don’t know, but it’s also quite energising. Learning is what drives me forward.

Writing a book helps me to visibly see the limit of my knowledge. I recognise what I can already explain easily, and what I need to research further before writing.

If I don’t know something, I search for it, and I go and learn.

Takeaway: Nobody knows it all.

Break it down into chunks

If I don’t have a concrete idea of the task I’m meant to be working on, I can easily get caught in minutiae and lose sight of the bigger picture.

This happened for a while before I properly started writing. I didn’t really know what I should be working on next. Now I have a Trello board for the book:

My Camel Step-by-Step board on Trello
My Camel Step-by-Step board on Trello

My Trello board helps to keep me on track. I create cards for book chapters and other tasks. When I complete a task, I mark it as completed, by archiving it.

I also use Trello as a bucket to store any other ideas I have. Some of these ideas will make it through into the finished book; I’ll try and be ruthless and cut the rest.

Takeaway: Break a big project into small chunks, and track it.

Writers’ block (it’s only a draft)

When faced with writer’s block, lower your standards and keep going

– William Stafford

Sometimes I write the same sentence three or four times, deleting it each time. Then I read it back and I sigh. It looks terrible.

I want every first draft sentence to be perfect and complete. But this causes me to get stuck. And then I wonder whether I’ll ever manage to write the sentence I want.

My solution in this situation is to follow the quote above: lower my standards and keep going. I grit my teeth, and I write the sentence anyway. I can always improve it later at the editing stage.

Takeaway: Just write. It can all be edited later.

I sweat the small stuff (window-dressing is real)

Even before I started writing, I had already decided that I didn’t want to use a word processor to write the book. I wanted the flexibility of writing it in plain-text, using a toolchain to typeset the book for me.

I might have finished the book earlier if I’d have used Google Docs or LibreOffice or Microsoft Word to write. But I would have been frustrated at the limitations of a WYSIWYG editor, and all that mouse-clicking. Thankfully at least losing entire documents in MS Word is a thing of the past these days.

Writing in Microsoft Word
Writing in Microsoft Word

Owning the entire process from end-to-end has been one of the big positives for me. I’ve enjoyed a lot of the small stuff, even down to things like choosing typefaces and formatting.

I decided to write using Asciidoctor, and I’ve learned a ton about it. I’m definitely going to use it for my next project! Recently, I’ve also discovered the Asciidoctor Maven Plugin for publishing, and from that I’ve learned a ton about Maven, too.

Creating opens possibilities

As I’ve learned new things while writing the book, I’ve also encountered new problems: things which I wish were solved.

I’ve discovered new frustrations, and that means potential problems to solve; things like improving the workflow for technical writers.

This gives me ideas for future side projects and little things to work on, that I wouldn’t have if I hadn’t started writing.

Takeaway: Start creating something (anything!) and you might find new problems to solve.

Write in the mornings, polish in the evenings

I always thought that I was “a morning person”. Writing a book has really confirmed that hypothesis.

I’m at my creative best in the mornings.

I’ve tried many times to write in the evenings, after getting home from work. Although I don’t feel tired, I just don’t get the same spark as easily as I get in the mornings. Mostly I just stare at the laptop screen, or get sidetracked by blogs and Twitter.

If I wake up early in the morning, as long as I know what my next task is, I can crank out 500 words before work, without a problem.

The key is to always know exactly what I’m working on when I wake up.

Takeaway: Join the “get up at 6am” club. (Not quite ready for the 5am club yet)

Tracking keeps me on… track

Strides, an iOS app I downloaded years ago for goal and habit-tracking, and which I’ve picked up again and found useful for tracking exactly which days I’ve been able to write.

I also track my progress via the total word count of the book. I use a simple Google Sheet and a chart to show progress as I move towards the finish line.

Here’s my not-quite-consistent approach to writing:

Word Count tracker
Word Count tracker

Takeaway: Set deadlines and track things.

Life gets in the way

Finally, life is just busy, especially as I am currently working away from home, in the beautiful city of Edinburgh. This means I travel Mondays and Fridays, so they’re less than ideal days to work on the book.

Busy busy busy
Busy busy busy

Expecting to be able to spend all your free time working on your side project? Then you’ll have less time to see your friends and family.

Those “how I crushed my dreams in 7 days” type posts on Medium can leave you with an unrealistic expectation of what’s actually possible in your own free time.

Life and work gets in the way, so I miss a few days every now and then, for seeing friends, meeting people, nights out with colleagues.

Takeaway: No project is worth sacrificing all social contact for.

To find out more about the book: https://cleverbuilder.com/camelstepbystep

Cover image by Joanna Kosinska on Unsplash