What to Keep and What to Remove

If I ask you to bring me a coffee from the local coffee shop, you might end up not buying the drink I wanted. But if I stop you before you leave for the shop, and tell you that I do not want a coffee after all, you can no longer make the mistake of buying the “wrong” choice between, say, an espresso and an iced coffee. Similarly, in software programming, there is a saying that the best piece of computer code is the one that is not necessary: you can simply remove it and the program will still run perfectly and flawlessly. While your readers are not machines, and while it is OK to repeat yourself to make a certain point, this saying also applies to your book. Ask yourself if a particular passage or paragraph is really needed to deliver your point. Unnecessary “fluff” not only increases the time you need to edit your book, but also decreases the weight of all the other points you are making.

This is an excerpt from Better Books with LaTeX, the Agile Way.‍

Shorter is always better: it saves you, your editor, and your reader time and elevates the other parts of your book that have a reason to be there. This applies both to fiction and non-fiction books. Introducing random characters you will never use again is just as problematic as explaining something that does not serve the point you want to make.

It is easy to fall victim to writing superfluous text. You are not only the person coming up with ideas for what to write about, but you are also implementing those ideas through your research and writing. In addition, you are looking at a computer screen or piece of paper rather than speaking to another person. These issues can lead to writing to yourself rather than to your readers.

To prevent this, imagine that you are wearing a different hat for each activity. Your state of mind and perspective on the text is different when planning, writing, or editing. To write better texts, it is best to not wear multiple hats at the same time. For now, let us put the writer’s hat down, put on the idea hat, and consider these questions:

• To whom are you writing?  e.g., First-time author.
• What does that person want to know?  e.g., What are the alternatives to Word?
• Why does that person want to know it?  e.g., Wants to streamline the e-book creation process.
• What is your goal with this particular passage? (for fiction books)  e.g., Introduce a character or plant a line of dialogue for a later payoff.

Once you have written down your answers to these questions, you can put your writer’s hat on again. You are now tasked with addressing the answers to those questions in a paragraph or section instead of going off on a tangent while thinking about new ideas.

The one trait of a good writer in this context is that he or she is following the instruction to the letter and will write only what is necessary to answer those questions, but no more. Once you are done with writing, you can again put on your “idea hat” and think about what your reader might want you to address next.

• Idea hat. When brainstorming about your chapters, or researching topics, you are wearing the idea hat. Take only minimal notes and focus on elaborating on the idea later.
• Writer’s hat. After having completed your research, you put on your writer’s hat and write, ideally without interruption.

This split between the idea person and writer can also take place on a larger scale. You can prepare an entire series of points you want to make in your book, noting whom you are talking to, what the person wants to know, and why he or she wants to know it, and then switch roles and do nothing but write those answers for a while. This will speed up your writing process by keeping you focused and reducing the time it takes to switch between roles.

In project management, this approach is called “creating user stories.” This is the method for creating user stories:

• Define your audience (“personas”);
• Brainstorm what your audience wants to read about and why;
• Divide your ideas into individual tasks relating to a specific persona;
• Put those user stories into a long to-do list (“backlog”); and
• Rearrange the user stories in your backlog so that their sequence flows logically (you will be working on them from top to bottom one after the other).

Once a paragraph or section is done, try putting yourself in the shoes of your readers and read it out loud. This will help you to write in a more personal, rather than distant, style. Also, it will be easier for you to remove parts that are superfluous and to improve the overall quality of your book by making it shorter and more to the point.

A good idea is also to take your concept and try to explain it to another person. If nobody is around, you might even give the “rubber duck debugging” method (the name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug the program code by forcing himself to explain it, line-by-line, to the duck) method a try: explain your idea to a rubber duck you hold in your hands. This is used sometimes in software engineering to clarify a problem and might also help you to get a different perspective on your own writing.

While discussing or working on a story, you might come up with new ideas. Instead of adding those on top of your existing story, you may want to think about whether it would be better to write a completely new story. For example, in this book, I discuss fiction and non-fiction books sometimes side by side, sometimes in separate chapters. When I do the latter, I have usually started with the former, and then decided to divide the chapter into two. A better approach is to split chapters as soon as you see that what you are writing might address two different audiences (we talk about “personas” in another article and the book) or deal with two distinct user stories. If you see this pattern repeating with other user stories, too, you might even want to think about moving the new user stories into a separate book.

Likewise, if you notice that individual user stories become too large, it might be useful to split them. Splitting can be done in various ways. For example, if your user story is “Clara wants to know how to publish her e-books online, so that she can manage the sales from her computer,” it could be split into several user stories dealing with different platforms (Amazon KDP, Google, etc.).

In following articles and the book, we discuss how you can come up with “personas,” which describe our readers. We will discuss how good user stories are written and what user stories I employed in this very book. And we will discuss the same for fiction books, which require a slightly different approach.