People ask me roughly twice a month why I write books while working full-time as an engineer. The implication is usually that it's an inefficient use of time. The honest answer is that writing has become the most valuable thing I do for my engineering career, and the books are an artifact of a habit, not the point of the habit.
Three reasons I keep doing it.
Writing is the best debugging tool for my own understanding
I learned this when I started the first book, Building AI Agents for Software Engineers. I had been building agents for clients for over a year. I thought I understood agents. The moment I sat down to explain what a tool-use loop actually does, in order, with no hand-waving, I discovered that half of what I "understood" was vibes.
I had an intuition for when things would work. I had no clean model of why. Writing forces a clean model. Every time I started a chapter thinking I knew the material, I'd hit a section where my mental model had a hole I had been navigating around. The book is the residue of patching those holes.
This happens with code too, but more slowly. Code lets you ship something that works without ever knowing exactly why. A book doesn't.
The books force me to test my experience against scrutiny
When I make a claim in a Slack thread, it lives for an hour and disappears. When I make a claim in a book that 4,000 people might read, I check it three times. I run the code. I read the docs. I look up whether the thing I remember from 2022 still holds. The friction is good.
The second book, AWS Cost Optimization, was where this hit hardest. I had opinions about FinOps from client work that I would have stated confidently in conversation. Half of them survived contact with the actual numbers. The other half were "true in 2022, partially true today, false in two AWS regions, complicated everywhere else". Writing forced the precision.
The third book, AI Security, is the one where I learned the most because the field moves the fastest. Threats from six months ago aren't necessarily threats today. Writing about it kept me current in a way that working on a single client project wouldn't have.
The reach is wider than the money
The royalties are fine. They're not the point. The real upside is people who reach out six months after the book ships and tell me they hit the exact bug I wrote about, the workaround worked, and they wanted to say thanks. That has happened often enough that I now keep a folder.
I've had emails from engineers at companies whose names I recognize. I've had emails from students preparing for AWS certifications. I've had one email from a person who told me they'd been about to deploy something the book specifically warned against, caught themselves at the last minute, and saved their team a 48-hour outage. I don't know whether they're exaggerating, but I'll take it.
That kind of reach is hard to get any other way. I could ship a feature this quarter that helps a hundred internal users. The book helps strangers for years.
If you're thinking about writing one
Do it. Even if 12 people read it, you'll be one of them, and you'll be a better engineer for it. The first book is the hardest by an unreasonable margin, mostly because you don't yet trust that your experience is worth writing down. It is. Whatever you've been doing for the past three years, write down what you learned, and ship it. The audience for "engineer who actually shipped this thing" is bigger than the audience for "expert".
Start with a small one. 80 to 120 pages is plenty. Don't write the magnum opus. Write the thing you wish someone had handed you 18 months ago.