Archive
Introducing The Hopeful Writing Series
As an engineer, as an engineering manager, and as a former Doc Bar Raiser with Amazon, I have a well-defined perspective on what makes a quality document, the process and thinking that goes into that outcome, and a clear vision of what I want my documents to achieve.
I’m sharing that with you.
Documents have the power to shape decisions
In most organizations, written documents are the primary way decisions are made, communicated, and revisited.
They capture:
- the problem
- the options
- the reasoning
- the recommendation
- and the plan for execution
They answer:
- What decision is required
- What is being recommended
- What happens next
- What happens if no action is taken
They become the shared reference point for people who were not in the same conversation or who engage with the decision later. The quality of the document directly affects the quality of the decision. Clear structure reduces interpretation. Specific language reduces ambiguity. Evidence allows evaluation.
When these are present, decisions move forward with less friction. When they are not, the cost shows up in delay, misalignment, and rework.
What this series covers
In this series, I share my perspective on approaches that produce a quality document. We focus on how documents behave in real environments:
- how purpose determines structure
- how structure shapes interpretation
- how language expresses ownership
- how evidence supports evaluation
- how recommendation and implementation affect outcomes
- how documents are reviewed in practice
Documents influence how organizations think and act. A well-structured document allows a reader to evaluate a decision once, with the right context. A poorly structured document requires the reader to interpret intent before they can evaluate it. The difference between those states determines how quickly work moves forward.
Let’s make that difference visible and repeatable.
Hopeful Writing is about writing documents that work—the kind that lead to clear decisions, shared understanding, and effective execution. It presents practical guidance grounded in expert feedback across real business documents. The result is a systematic approach to writing that prioritizes usefulness over polish.
A Shattered Trinity: A Symphony In D Major
I’ve always wanted to write a full symphony. I like the structures, I like the idea of having to compose for such a large group of instruments, and I like the flexibility I get beyond my more guitar based influences, although I also enjoy writing songs in that mode. So one day I asked ChatGPT to describe for me an example structure for a Baroque style symphony. That outline led to my most recent work.
There were song structures I’d never heard of, tempos I’d never composed in, time signatures I’d never thought to attempt despite my foray into odd meter on nearly every album I’ve published. Any other time I’ve tried to start an idea like this I’ve experienced writer’s block trying to come up with compelling themes, especially considering I didn’t quite understand how to use themes in classical music in the first place. But I recalled a simple bit of melody from Servings Of Sadness that had come to me as I sang it to myself while making lunch, and decided if it was compelling enough to be sung, it would be a compelling enough start. That six note motif became the Motto, the base, for the set of themes I crafted for my symphony, including a theme each for the two protagonists, a Love Theme, a Battle theme, and more.
I found many of the structures limiting at first; fugues in particular with their predefined key changes were difficult. On occasion I would get stuck, and when I couldn’t get myself out, I’d take some advice from ChatGPT on potential solutions. Eventually, the story became evident: two young men, friends in fact, fall for the same young woman in a Renaissance era city filled with festivals and joy. The city itself is a character, an observer, to a tragic tale of love and loss.
Three concertos and an orchestral suite later, A Shattered Trinity is born.
You can learn more about this album here.
Available on Spotify, YouTube, and Amazon Music.

An Occasional Coding Exercise Leads To Puzzle Book Sales
There was a time back in my early Amazon career, when I was managing the Independent Publisher Portal, also known as Kindle Direct Publishing, that I wanted to end to end test the publishing process for print on demand. The challenge with doing so was that the publishing workflows were really good at recognizing duplicative content as part of its fraud detection. This made testing repeatedly close to impossible, because each test required a new, unique book.
I decided to pop open Visual Studio, fire up my rusty C# skill, leverage Microsoft Word’s XML based formatting, and write some code to automatically generate books. Because I wanted them to be legitimate, repeatable, and make it to the Amazon marketplace, I couldn’t just randomly generate text files.
So I wrote a program that automatically generated Sudoku puzzles. First, I wrote a randomizer that would generate a random 9×9 sudoku grid filled with a solved and valid result. Then I wrote a sudoku solver to validate that the puzzle in its final form had a solution.
I then decided I wanted to have three different levels of solvable sudokus, with about 30 of each in a book. So, for each level, I removed a certain number of random digits from the puzzle, one by one, until the solver determined that the puzzle was no longer solvable. I then stepped back to the last solvable version and marked that as a “hard” puzzle, added two more digits back for a “medium”, and then two more digits back for an “easy” puzzle.
With that code written, I went online and downloaded a free use sudoku puzzle image, and created a Word document template including the cover file. I saved that file so I could open it later, along with a few fields I could merge in, such as the volume number, as well as the colors for the cover so any books I created could be unique. With that, a few parameters could be passed in to my program, generate 60 puzzles, add them as pages to the Word document, and save out a new, unique puzzle book.
I was able to successfully test my publishing workflow. Ten of these puzzle books were published out to Amazon. They remain available for sale today, and I still occasionally sell one.

With that done, I decided to go back and write a different puzzle output, adding a dictionary integration and code that created word search puzzles. There are ten of those out at Amazon as well. It was a fun little project that took a bit of thinking to get through, and over the course of several years managed to pay for a couple of dinners.
