The first draft is where most technical book projects live or die. Many aspiring authors research thoroughly and plan meticulously, only to stall when it comes time to fill blank pages. This chapter is about getting words down efficiently without getting paralyzed by perfectionism.
This might be the most important sentence in this entire book: your first draft will be bad, and that is fine.
The purpose of the first draft is to exist. It transforms your outline and notes into prose that can be improved. You cannot edit a blank page. You cannot get feedback on ideas that live only in your head.
Give yourself permission to write poorly. Write explanations that are too long. Write examples that are clumsy. Write transitions that feel awkward. All of this is fixable — later.
You do not have to write chapters in order. If Chapter 5 is the topic you know best and are most excited about, start there. Early momentum matters more than sequential order.
The only rule: make sure your first three chapters are polished early, because if you share the book for feedback, those are the chapters people will read.
Some authors prefer to build confidence with an easy chapter before tackling the challenging ones. An introductory chapter or a chapter on a topic you’ve written about before can be a good warm-up.
The introduction is deceptively hard to write because it requires you to know what the rest of the book contains. Write it last, or at least rewrite it after the other chapters are complete.
Technical writing requires deep focus. Aim for 60-90 minute writing blocks with no distractions. Close email, silence notifications, and resist the urge to check anything. Two focused hours of writing produce more usable content than six distracted hours.
Do not edit as you write. If you notice an awkward sentence, leave it and keep going. If you realize a previous paragraph needs restructuring, make a quick note and move on. Constantly switching between creation and criticism kills your flow.
Practical technique: if you need to come back to something, insert a marker like [TODO: fix this] or [REVISIT] and keep writing. You can search for these markers later.
While you can write chapters out of order, write each chapter top to bottom. This ensures a natural narrative flow. If you write sections in random order within a chapter, they tend to feel disconnected.
Imagine your target reader is sitting across from you. How would you explain this concept to them? Technical writing does not need to be formal or stiff. The best technical books have a conversational, direct tone.
Read your sentences aloud. If they sound unnatural, rewrite them the way you would say them.
Most technical explanations follow a three-part pattern:
Do not skip any step. Context without concept is vague. Concept without example is abstract. Example without context is confusing.
Start with the simplest possible version of a concept. Then add layers of complexity. This is how humans learn — we anchor on a simple mental model and refine it.
Bad approach:
“Here is the complete configuration with all options explained.”
Good approach:
“Here is the minimal configuration that works. Let’s understand each line. In the next section, we will add error handling. After that, we will optimize for production.”
Analogies can illuminate or mislead. A good analogy maps accurately to the concept and breaks down at a predictable point. A bad analogy creates false intuitions that the reader must unlearn later.
When you use an analogy, acknowledge its limits: “This is like X, but the analogy breaks down when…”
Put yourself in the reader’s position. Where would you get confused? What questions would you ask?
Address these preemptively:
Technical content is already complex. Do not add complexity with convoluted sentence structure. Short, declarative sentences are your friend.
Bad: “The configuration file, which is located in the root directory of the project and which is read by the framework during the startup phase, contains the settings that determine how the application will behave in different environments.”
Good: “The configuration file lives in the project root. The framework reads it at startup. It controls how the application behaves in each environment.”
Use active voice. The subject performs the action.
Bad: “The request is processed by the middleware.” Good: “The middleware processes the request.”
Address the reader as “you.” This creates directness and engagement.
Bad: “One should ensure that the tests pass before deploying.” Good: “Make sure your tests pass before deploying.”
Use the simplest correct term. Do not write “utilize” when you mean “use.” Do not write “leverage” when you mean “use.” Do not write “facilitate” when you mean “help.”
Introduce technical terms when they are necessary, define them clearly, and then use them consistently.
Every author faces it. The key is to have strategies ready:
Anne Lamott’s advice applies perfectly to technical writing: give yourself permission to write a terrible first draft. The goal is completion, not quality. Quality comes in revision.
Every code example in your draft should work. Copy-paste it into your development environment and run it. Broken code examples are the fastest way to lose reader trust.
During the first draft, make sure code works but don’t optimize it for readability. You will revise code examples during editing, just like you revise prose.
Keep a list of things you need to verify:
Do not let these questions stop your writing. Note them and keep going.
Track words written per session, not hours spent. You can sit for three hours and produce nothing, or write 1,000 words in 45 minutes. Words on the page are the metric that matters.
Completing a chapter is a genuine accomplishment. Completing the first draft is a major one. Acknowledge your progress — it sustains motivation over a long project.
| ← Chapter 3: Research and Preparation | Table of Contents | Chapter 5: Code Examples and Exercises → |