The Tech Drama 1.0.2, coming.
TL,DR;
Similarities between authoring a book and software development
Improving my process as an author/editor
Some embarrassing typos
After 4 years of work, 2 editors, 1 beta reader, countless personal reads, and a pair of “final” reads, I thought I had my book perfected. I knew there were a few issues. I am the type of person who can look at a page and has misspelled words pop out at me. I used to sit with graphic designers and have to keep from pointing out when images were offset by 1 pixel, to stay focused on the greater task.
A few themes from my life as a software engineer, engineering manager, and product manager:
You will never find every bug (typo).
I really thought my spelling was good enough to not run the spell checker. Then, I ran it before my final proof and found ~40 misspellings through ~195,000 words. That’s a misspelled word every 15 pages. I was really happy I had done it. From a grammar perspective, I assumed the grammar checker would beat up on my colloquial style. I’m informal. So, I didn’t run it.
A few days after release a close friend asked me, “I think I’ve found something. Maybe it’s the way Kindle formats things, but you might want to check it out.”
I thought for sure it was how Scrivener formats for Kindle. The issue was:
When I checked the manuscript, the duplicate words were definitely in there. It wasn’t Kindle. It was me.1 Again, I had just read that text. It had been there for months. My brain just went past it. It had slipped past the editors doing developmental reads and my beta reader who had editing experience.
I ended up running Scrivener’s grammar checker, which I should have done in the first place. One of my lessons of dealing with the events that inspired The Tech Drama is to not beat myself up over these things. However, I recognize that an old me would be sick with things like:
This one is particularly embarrassing.
So, I’m putting out The Tech Drama 1.0.2, with about 20 corrections, including 10+ duplicated words.
Let’s touch on another lesson.
When you fix something, don’t break something else
Seems obvious. However, we’re in the “Move fast and break things,” era. “Bias towards action.” Both ethos skip the idea that you need to fix things and not make things worse. The point of agile, PDCA, OODA is to get to small victories, rapidly, knowing you may fail. The thing about it, the cost of putting defects (typos) in front of a user are still costs. If your brand becomes known for being shitty, people will look for alternatives. I happen to want my book to be good.
During authoring, there were times when I went to delete text in a “find” window and it looked like my word processor wasn’t responding. When I paused I would find that I had deleted text from my manuscript. I’m sure I did this more than once without noticing, and caught the issues in editing.
With v 1.0.2, I don’t have time to reread the entire manuscript. Even if I did, I would surely miss things. With software development, this is where we used automated tests. I considered my options. 2
In the end, I found that I could use Adobe Acrobat’s compare documents feature to compare my last document with my current one.3 This works to verify I didn’t make any inadvertent changes.
I’m not sure what else could go wrong, but I’ve done what I think is “due diligence,” to…
…Make it better, keep improving
I think 1.0.2 is a better version of The Tech Drama.4
I’ll push the changes today. Amazon asks for 72 hours to update, but often it has taken a few hours.
If you bought v.1.0.0, you should be able to update your Kindle version. If you have a print copy and want a cleaner version, get in touch. I haven’t found anything that affects the meaning of the book.
Kudos to Kindle for being deterministic. Every time I see a defect these days my first thought is, “did I just download a vibe coded update?” In this age of AI and probabilistic messes, it’s great to be able to assume things work in a predictable way.
LLMs were definitely an option, particularly a local one. However, the context window was too large for a single LLM. I probably could have used an agent to do the work and it would have done a very good job, though probably would have taken a lot of tokens.
It works well, when page counts stay the same. When page #’s change, Acrobat catches every number and every recto/verso heading change. Last time I did this comparison, I had 1200+ changes reported, but only 5 were material. However, with this version, I only have 30 changes.
In the future I might build a continuous integration pipeline with automated tests, but we’re not there at the moment. Maybe for book 2.