One of the things I tell myself is that many of these very difficult experiences were also growing ones for me. I, of course, would prefer that the friends and family I lost or who got sick were still here and healthy. But I also have a greater empathy and understanding when I interact with other people going through these same tribulations.
> It's interesting to hear how you had the code pegged down for this book at the start. The book definitely feels like the result of such considered and planned design.
I basically had to write it this way. My previous book was like a recipe book where each chapter is relatively unconnected so I could just start writing. But this book walks through two complete implementations of the same language, which I also designed for the book. So just about any tiny change to anything can affect very distant chapters.
I wasn't even sure if the book would hang together until I designed the language and wrote the code. If I couldn't get to a little toy language I liked or if the implementations had been a sprawling mess, I would have passed on the project. But a couple months in, everything kind of clicked and I realized I basically had to the write the book. It's like the thing was already there and I was just responsible for putting it all down on paper.
> I also attempt that in my writing, but almost always end up dragging myself down rabbit holes, including rewriting/renaming/restructuring entire code scripts/snippets, if not the project codebases that I've drafted and refer to.
I do a lot of that too. Fortunately, having the code pinned down helps. I basically can't touch the code now because doing so would destabilize existing chapters. The fact that I publish incrementally also keeps me from endlessly noodling.
But it is always a struggle to rein myself in and stay focused on making forward progress.
It's interesting to hear how you had the code pegged down for this book at the start. The book definitely feels like the result of such considered and planned design. But one of the features I most appreciate in your book are your reflective asides, such as the Design Notes [0]. I also attempt that in my writing, but almost always end up dragging myself down rabbit holes, including rewriting/renaming/restructuring entire code scripts/snippets, if not the project codebases that I've drafted and refer to. Guess I can't delude myself into thinking such bikeshedding is inevitable for this kind of writing!
[0] "Logic versus History" https://craftinginterpreters.com/parsing-expressions.html#de...
"What's in a Name" https://craftinginterpreters.com/introduction.html#design-no...