Generated using AI. Be aware that everything might not be accurate.


Chapter 3: Research and Preparation

Writing a technical book without thorough preparation is like building a house without foundations. The research phase ensures accuracy, depth, and credibility. It also prevents the most painful kind of rewrite: discovering halfway through that your mental model of the topic was wrong.

Know More Than You Write

You should understand your topic at a level significantly deeper than what appears in the book. If your book teaches intermediate concepts, you need expert-level understanding. This surplus knowledge shows up in subtle ways: the precision of your explanations, the quality of your examples, and the confidence with which you handle edge cases.

This does not mean you need to be the world’s foremost expert. It means you need to do the work to fill gaps in your own understanding before asking readers to trust you.

Types of Research

Primary Research: Hands-On Experience

The most valuable research for a technical book is doing the thing yourself. Build the projects. Run the commands. Hit the errors. If you are writing about deploying applications to a cloud platform, deploy real applications. If you are writing about a programming language, write substantial programs in it.

Primary research gives you:

  • Authentic examples: Real code you actually wrote, not contrived snippets.
  • Knowledge of pain points: You discover what is genuinely confusing, not what you imagine might be confusing.
  • Credibility: Readers can tell when an author has real experience versus when they are paraphrasing documentation.

Secondary Research: Reading Existing Material

Read everything relevant:

  • Official documentation: The canonical source of truth. Read it cover to cover, not just the sections you think you need.
  • Competing books: Study how others approach the same topic. Note what they do well and where they fall short.
  • Conference talks and videos: Talks by core maintainers and power users often reveal design decisions and best practices not found in documentation.
  • Source code: For open-source technologies, reading the source code gives you the deepest understanding. You do not need to read every line, but key modules and interfaces are invaluable.
  • Issue trackers and forums: Stack Overflow, GitHub Issues, and mailing lists reveal the real-world problems people encounter.

Expert Interviews

If possible, talk to people who use the technology in production. Their insights will ground your book in reality. Ask them:

  • What do you wish you had known when you started?
  • What are the biggest misconceptions beginners have?
  • What does the documentation get wrong or leave out?

You do not need to quote them directly. Their input shapes your understanding and priorities.

Building a Knowledge Base

As you research, organize what you learn. A chaotic collection of bookmarks and notes is nearly as useless as no research at all.

  1. Create a notes file per chapter: As you research, drop relevant findings into the corresponding chapter’s notes. Include links to sources.

  2. Maintain a glossary: Technical books use precise terminology. Keep a running glossary of terms and their definitions. This ensures consistency throughout the book.

  3. Track unanswered questions: Keep a list of things you don’t yet understand. These are your research priorities.

  4. Save code snippets: When you build examples during research, save them in a dedicated repository. Tag them by chapter or concept. You will refine these into the examples that appear in the book.

  5. Record version numbers: Technologies change. Note exactly which versions you are working with. This information belongs in your book’s preface and is critical for reader trust.

Building the Example Project

If your book includes a running example or project, build it during the preparation phase — not while writing chapters.

Why Build First

  • You discover the natural order of concepts by experiencing the build process firsthand.
  • You catch issues (dependency conflicts, breaking changes, unclear APIs) before they derail your writing.
  • You have a complete, working codebase to reference while writing.

How to Build

  1. Start with the simplest possible version that works.
  2. Incrementally add features in the order you plan to teach them.
  3. At each stage, commit your code and tag it with the chapter number. This creates snapshots readers can check out.
  4. Run the complete project from a clean environment to verify that your instructions work from scratch.

Setting Up Your Environment

Before writing, establish:

  • A code repository: Use version control for all example code. Public repositories let readers clone and follow along.
  • A reproducible environment: Use Docker, virtual environments, or similar tools so your examples work consistently.
  • A testing setup: Write tests for your example code. If your code breaks during the writing process (due to library updates, for instance), tests will catch it.

Estimating the Scope of Work

With your research and table of contents in hand, estimate the size of your book.

Chapter Length Estimation

A typical technical book chapter is 15-30 pages (5,000-10,000 words). Estimate each chapter individually — some will be longer, some shorter.

Total Book Size

Most technical books fall in the range of 200-400 pages (60,000-120,000 words). If your estimate is significantly shorter, your scope may be too narrow. If it’s significantly longer, consider splitting into multiple volumes or cutting topics.

Time Estimation

Writing speeds vary enormously, but a realistic pace for a technical book is 1-2 chapters per month when writing part-time alongside a full-time job. A 12-chapter book might take 8-14 months of writing, plus time for editing and review.

Do not underestimate the time required. Most first-time technical authors take longer than they expect.

Creating a Writing Schedule

Set a schedule and stick to it. The biggest risk to any book project is abandonment due to loss of momentum.

Strategies That Work

  • Fixed writing time: Write at the same time every day or on the same days every week. Regularity builds habit.
  • Word count targets: Set a daily or weekly word count goal. 500-1,000 words per writing session is realistic for technical content.
  • Chapter deadlines: Give yourself deadlines for each chapter. Share them with someone who will hold you accountable.
  • Buffer time: Plan for life to interrupt. Build buffer weeks into your schedule for illness, travel, and motivation dips.

The Minimum Viable Habit

If you can commit to writing 500 words per day, five days a week, you will produce a complete first draft in 6-10 months. That is 30 minutes to an hour of focused writing. The key is consistency, not bursts of inspiration.

Key Takeaways

  • Know your topic deeper than what appears in the book.
  • Combine hands-on experience, existing materials, and expert input.
  • Build the example project before writing about it.
  • Organize research by chapter with linked notes and sources.
  • Estimate size and time realistically — most authors underestimate.
  • Establish a consistent writing schedule and protect it.
← Chapter 2: Structuring a Technical Book Table of Contents Chapter 4: Writing Your First Draft →

>> You can subscribe to my mailing list here for a monthly update. <<