12/31/2025
See the discussion of this post on Hacker News.
Update: Many people reached out expressing their interest to buy the book. I've put the e-book up for pre-order. I'll release each chapter as they are completed. A print version will be available on Amazon later.
Back in 2020-2022, my blog was getting a lot of attention. Some of the big tech book publishers reached out about whether I was interested in writing a book. I had a few conversations but decided against it. I did want to write a book but self-publishing seemed like the better option.
Then an acquisitions editor for another big publisher asked to chat. He had a similar background to me, an academic who enjoys coding and writing. He had written a few books for multiple publishers so he knew the process and wasn't shy to share the good and bad. He even made decent money from his books.
I was intrigued. Writing a book was one of those goals that I liked the idea of but never made any progress on. I went and talked to a few other people that had published technical books and they gave me their reviews of the process and of each of the big publishers.
- Pros of a publisher: They are a forcing function to make progress, they handle a lot of logistics for you around the book, they provide some feedback on the content, they have large distribution channels, and it looks more "real" when a publisher's name is on your book.
- Cons of a publisher: They nag you constantly, they may try to steer your book in other directions, the money is peanuts, they can stop printing the book whenever they want, they have control over future editions, and they actually do little to no marketing of your book.
I decided to write a book and sign with the publisher!
The topic
Before the actual deal, we had to agree on the book. Each publisher has their own template for pitching an idea. I did that and we went back and forth on some of the details. This part felt collaborative, they were trying to help me flesh out the concept based on their data and experience.
A lot of my blog posts involve classic programming projects that were relevant 30 years ago and will be just as fun 30 years from now. What if the book is a collection of tutorials on building these projects, each self-contained and teach fundamental computing concepts along the way?
To motivate that there is a market for this, I showed them that several of my blog posts in this space collectively had millions of views. Most notably, Challenging programming projects every programmer should try (and the two sequels). My readers seem to resonate with making useless stuff and programming for fun. Who doesn't love hacking on a ray tracer or compiler or game or operating system just for fun?!
Page view spikes from my blog hitting up to 80,000 unique viewers a day.
They liked it! It was quite different than many of their other books. I wrote a high-level outline of the entire book. The projects were going to be:
- Web crawler
- 2d game
- Compiler
- HTTP server
- Drawing app
- CHIP-8 emulator
- TBD
- A list of mini projects
The compiler chapter would be a revised version of my Let's make a Teeny Tiny compiler blog series. The last project chapter would list a bunch of smaller scale projects that are less of a commitment but still worthwhile for learning (e.g., an image file format converter). Also, each chapter would end with a bunch of suggestions on how to continue with the project. If I got to the end and the book was a bit short, I was planning to squeeze in one more project chapter too.
The contract
There was some negotiation of the contract terms. We had to agree specifically on what the book was going to be. This included the pitch for the book, who the intended audience is, and a very detailed Table of Contents (down to the subsubsection headings). I had to give a tentative schedule of when I'd deliver drafts for major milestones.
The weirdest thing in the contract was the number of illustrations that the book must contain. I asked to bump that up. In the end we agreed to 115,500 to 132,000 words in length, approximately 350 to 400 printed pages, with 10 to 30 illustrations.
They offered a $5000 advance with the first half paid out when they approve of the first third of the book and the second half when they accept the final manuscript for publication.
I didn't even bother negotiating this because it is essentially nothing. I have a day job so I don't need the money sooner to pay rent (it is just an advance after all!) and if I don't sell way, way more than that then this was a bad use of my time financially anyway.
The royalties offered were surprisingly low. I did negotiate these and got them bumped up a tiny bit. They agreed to 12% of total sales for print and e-book on the first 7000 copies and then 15% on sales after that. 50% royalty on foreign translation sales.
I was later told that some people negotiated up to 18%. Meh. The finances don't look great regardless unless you have one of their top books.
They refused to share statistics. I was able to get out of them that their median book sells in the range of single thousands of copies. Their top sellers are in the range of hundreds of thousands of copies but they only shared one example of a book that did that. Most are on the shelf for only a few years.
Oh, and I get 25 copies for myself and I can buy copies at a 50% discount.
We kicked the project off in early 2023.
Get to writing!
They assigned me an editor that I met with regularly. This was my main contact with the publisher.
He walked me through the process and got me set up. I was required to use AsciiDoc or Microsoft Word for my drafts. Nope, I can't use LaTeX. He gave me a very detailed style guide that I had to follow.
He emailed me, a lot. We had initially agreed to a chapter draft every 3 or 4 weeks (I was overly optimistic, and felt pressured...). Once that first soft deadline passed, the constant emails asking to see drafts began.
When I delivered a draft, I quickly got a marked-up version back. The feedback was mostly formatting and styling. The helpful feedback was pointing out rough transitions or assumptions I made about prior knowledge.
The unhelpful feedback was a consistent push to dumb down the book (which I don't think is particularly complex but I do like to leave things for the reader to try) to appease a broader audience and to mellow out my personal voice. He also wanted me to add a chapter that acts as an intro to programming with Python... 😵
"There needs to be an initial chapter for teaching Python in case the reader doesn't have the background. What if they don't know how to use pip to install packages?"
It became clear that they were following a formula for technical books. Don't show too much personality, don't be too technical, and hand hold the reader through a linear task. Just crank out the book so they get the book on the shelf. What you say on page 120 doesn't matter because the reader has already bought the book.
This rubbed me the wrong way but I pushed through. They are just following their incentives and I should push back.
AI, AI, AI
The book was started only a few months after the release of ChatGPT. The entire world was talking about AI!
So it wasn't long before the publisher asked to chat. "Hey, is there any way you can incorporate AI into the book?", I politely declined.
A bit later they come back basically saying The Powers That Be are requiring AI to be part of every book. I offered a few compromises (i.e., a chapter about implementing an ML algorithm or a note at the end of each chapter about leveraging AI in the creation of the projects). I got a mixed response.
"All of our future books will involve AI."
In the end, I firmly told them no. It is antithetical to the premise of the book (classic programming projects!) that they agreed to publish. They went away.
Getting closer?
I kept missing deadlines. I was busy with work (AI!) and life. Apparently every book's timeline gets pushed at least once, so they were flexible. I eventually sent the editor the first third of the book and we made a few back-and-forths revising it.
This triggered the next stage: getting feedback on the technical content. We would do a round or two of this with a technical editor, then the draft would go off to strangers for review. If they hated it, the publisher had the right to cancel the project. If they don't hate it, then the draft would go live for early readers to buy (and they'd receive future chapters as they are completed).
The first notes I got back from the technical editor didn't seem like a good fit. Everything he said was correct, but indicated a mismatch in expectations. He was critiquing the project in the chapter as if it was supposed to be production quality software. But my projects are a balancing act of what can any programmer with very little knowledge on the subject make in a weekend that gives them a broad understanding of the concepts.
The second chapter of feedback from the technical editor was far more helpful to me. I think he "got" what I was going for and pointed out many flaws and suggested many improvements I could make. It was nice. Iterating on existing content is a very different workflow than writing new content so I slowed down even more. For example, it can be quite tedious to make sure that code snippets are consistent with snippets from 20 pages prior.
Life
I continued to get further behind on delivering my revised draft of the first 1/3. This is a big milestone in the publisher's process (soliciting external reviewers, determining whether the project should continue, putting the early adopters e-book up for sale, and paying out the first half of the advance).
The publisher was getting grumpy. I was getting grumpy. They were bringing up pivoting the book to be about AI again. They were "reevaluating" their portfolio. My editor left the company and I was assigned a new one. Things were piling on.
There was also a daunting voice in the back of my head that LLMs have eliminated the need for books like this. Why buy this book when ChatGPT can generate the same style of tutorial for ANY project that is customized to you?
The process with the publisher wasn't enjoyable. I had hoped for it to be a positive motivator to keep me focused but it felt like a chore. And I was worried that the finished product would be void of personality and would be yet another boring programming book.
Around this time, there was a possibility of me changing jobs. Oh, and my wedding was coming up. That was the final nail in the coffin.
Photo from my honeymoon while not working on the book.
The end
There were too many things going on and I didn't enjoy working on the book anymore, so what is the point? I made up my mind to ask to freeze the project.
They agreed.
I think they thought of this as a temporary cooldown where I could sporadically work on the book without the stress of the deadlines. The new editor still pinged me regularly asking if I made progress. Repeatedly. (I suppose they are following the incentives again—they only get paid if people ship books.) Eventually I asked him to stop until I reached out first.
And then... life went on. I never got un-busy.
Fast forward, I just got notification from the publisher that the contract has been officially terminated and all rights of the work were transferred back to me.
I still love my book idea. Maybe I'll just publish the chapters as blog posts or self-publish it!
Many people reached out expressing their interest to buy the book. I've put the e-book up for pre-order. I'll release each chapter as they are completed. A print version will be available on Amazon later.
