Posts tagged “publishing”
If you have a blog, you can use it within a fast feedback workflow: If you have an active community, you can rely on this fast feedback and have many editing iterations for your text. This improves many Zettel in your Zettelkasten, which is especially nice if you plan to craft a book out of them.
What if you could publish iteratively, bit by bit, at each step gathering feedback from your readers and refining the text. Would our writing be better? Iteration in public is a principle of nearly all good product design; you release a version, then see how people use it, then revise and release again. […] The faster the release cycle, the more opportunities for revision—and, often, the better the product itself.
—“Deploy” by Mandy Brown
This resonates well with me. I tackle a lot of real-life problems in the way of your typical programmer. I try to find problems, invent solutions, test and revise. I think this would work great in science writing, too. (Read the article and the other parts of the series. In fact, go and take a look at the whole website.)
I find programming highly enjoyable because of the iterative nature of the process. It feels nice to write software I’d love to use myself. And it’s even nicer to have a second application behind the scenes which tests the code I write continuously. I end up with multiple iterations daily: not just product release iterations but development iterations.
An approach called Test-Driven Design appeals to me: write the tests first, then write code for the application which makes the test pass. This way you don’t add stuff you don’t need or which isn’t tested (and thus cannot break without you knowing).
Test-Driven Writing is a label I invented myself. Write iteratively, but specify the outcome first in a separate document. There’s no document describing the technique. It’s just a few Zettel notes. There’s still lots of research and experimentation needed to make this a real thing.
Apart from micro-iterations, publishing early and publishing often seems to be a good idea still. It doesn’t even need any special technique. Just publish it before it’s finished, and revise.
A book, like large software, is never finished – only released.
Now I’ve got two books on programming out already. One is about 80% done, one is only 20%. I talked about the first one already. The second one took me a while, but I decided not to put off the release by fear of delivering sub-par results. I rather tell people that they can help me make the book better but shouldn’t expect a complete and revised edition. Then I improve the text and add details.
To defer publishing until sometime later is almost always a bad idea: you will build up anxiety. Steven Pressfield’s book Do the Work2 was a great motivational tool for me to get past the fear of publishing.
Leanpub is a great platform to write texts and get back e-book files to share with the world. It encourages you to write something, publish it in an early release version, then write some more. Anxiety is optional.
Ash Maurya (2012): Running lean. Iterate from plan A to a plan that works, Beijing: O'Reilly, p. 19. ↩
Win-win affiliate links: we get a small kickback from amazon if you buy from this link but it won’t cost you anything. ↩
The first “first draft” I ever finished was a short-ish ebook about writing. I tend to be very heavy on research with my projects. As I realized that my Zettelkasten archive already contains content worth several books, I started to research on how to write a book. The Zettelkasten Method means that you embrace a technique that is called “Schreibend lesen” in German – a phrase Luhmann coined in his later days. It means that you write while you are reading a text. Writing and capturing the ideas in your own words enhances your understanding and thinking on the topic, and perhaps in general.1