Writing a 120,000-Word Book While Building Software Full-Time
In December 2024, I finished the first draft of a 120,000-word book on trading. 24 chapters. That's roughly the length of two Harry Potter books.
I wrote it while simultaneously building the Nexural platform — 185 database tables, 69 API endpoints, a Discord bot, and this portfolio site. Full-time engineering. Full-time writing. Full-time trading.
People ask "how?" The answer is less inspiring than you'd expect.
The System
I wrote 500 words per day. Every day. No exceptions.
500 words takes about 30-40 minutes. Some days it was 20 minutes because the ideas were flowing. Some days it was an hour because every sentence felt like pulling teeth. But the minimum was always 500.
At 500 words per day, 120,000 words takes 240 days — about 8 months. That's it. No sprints. No weekends of marathon writing. Just 500 words, every single day.
Why 500 (Not 1,000 or 2,000)
I tried 1,000 words per day in the first week. By day 4, I was burned out and skipped a day. That skip became 3 days. Those 3 days became a week.
500 words is low enough that I never have an excuse to skip. "I don't have time" doesn't work when the task takes 30 minutes. "I'm not feeling inspired" doesn't work because 500 words of bad writing is still 500 words closer to done.
Bad pages can be edited. Missing pages can't.
The Chapter Structure
Every chapter follows the same template:
```
- The Core Concept (what is this thing?)
- Why It Matters (why should the reader care?)
- How It Works (the mechanics, with examples)
- Common Mistakes (what goes wrong and why)
- How I Apply It (personal experience from real trading)
- Key Takeaways (3-5 bullet summary) ```
This template saved me from writer's block. When I didn't know what to write, I'd pick the next empty section in the current chapter and fill it. Structure eliminates the blank page problem.
How Writing Made Me a Better Engineer
Here's the unexpected part: writing a book improved my software, not just my writing.
Explaining forces understanding. When I wrote the chapter on risk management, I realized my own risk management in AlphaStream had gaps. I was computing VaR but not CVaR. Writing about it forced me to implement it properly.
Documentation became natural. After writing 120K words, writing a README or ADR feels effortless. The muscle of explaining technical concepts clearly transfers directly to engineering documentation.
Long-term thinking improved. A book requires planning 24 chapters that build on each other coherently. That same skill — thinking about how components interconnect over a long timeline — is exactly what systems architecture demands.
What Nearly Broke Me
Chapter 18 — options pricing theory. I spent 3 weeks on Black-Scholes derivations, realized I was writing a textbook chapter (not a practical guide), and deleted 8,000 words.
Deleting 8,000 words that took 16 days to write is physically painful. But the chapter was wrong for the book. It was impressive to write but useless to read.
The engineering parallel: I've deleted features that took weeks to build because they didn't serve the user. It hurts the same way. And it's the right call the same way.
The Editing Phase
First drafts are terrible. All of them. The book is currently in editorial phase — I'm cutting 20% of the content (about 24,000 words) to make it sharper.
The editing process is identical to code review:
- Is this section necessary? (Does this function need to exist?)
- Could this be said more clearly? (Could this code be simpler?)
- Is this in the right place? (Is this logic in the right file?)
- Would a reader get lost here? (Would a new developer understand this?)
The Takeaway
Writing a book is a project like any other. Break it into small daily tasks. Have a template so you never face a blank page. Be willing to delete what doesn't serve the reader. And ship it — an imperfect published book helps more people than a perfect unfinished manuscript.
The same applies to software, to portfolios, to careers. Ship the imperfect version. You can always iterate.