In my non-fiction writing, I’m nearing the end of a book. The essential (and hard part) of concocting examples, making them work, and then describing them is done. Since the book is about programming, all the examples are code and a technique called “automated testing” assures that the code examples all really work.
There’s little real drama in technical writing.
It’s difficult to manufacture drama around software. Not impossible, but… Trying to impose a narrative arc on software feels contrived.
If software solves a compelling problem, then the problem is of interest and the software is nothing more than a plot device. Even if I wrote the software. And even if it’s really cool.
The software itself — it’s design or organization — can’t be very compelling. I can describe design alternatives as “competing”, but, they’re only competing points of view. To create drama, the alternative designs would have to have something at stake, some skin in the game. I’d have to turn competition for precious resources (like CPU time) into some kind of winner-take-all conflict where one algorithm lives and the other dies.
(Really? Where would a dead algorithm go? How does an idea cease to exist?)
Does an optimized loop really crush the life out of a recursion? Does a hashed lookup in a dictionary really snatch the CPU time from a list traversal? It’s difficult to create conflict among points-of-view or patterns of software design.
The patient review of the chapters must be done carefully and completely. And without any drama.
The Tales of the Red Ranger has to be set aside until the prefinals have been reviewed. Right now, I’ve got six (or so) long-running thematic issues to square away. There’s a horror aspect to the Mage’s struggles that’s not fleshed-out in the current draft.