Been sifting through my blog subscriptions today for a while an found a few articles I ended up liking: Recently, there was a to-the-point XKCD comic about Survivorship Bias. So much for success formulae. ↩
Posts tagged “writing”
I managed my writing ideas in a to-do list for years. Since I follow the principles of the Getting Things Done methodology, a book idea was the perfect candidate for a “someday/maybe” project. That’s a project which you can prepare with anything from the top of your head without much real planning. You don’t have to follow-up on it anytime soon if you don’t want and thus defer taking any action until later. You can have ideas now and execute them later, whenever you wish.
Last week I completed a script to help automate the process of compiling a first draft from an outline and Zettel notes. You can find it on GitHub or install it as a gem from the terminal:
gem install zettel_outline. Learn more about the format it supports and how you can adopt it to your Zettelkasten note archive.
After Sascha’s great release of the Zettelkasten book, here’s a short e-book from yours truly. It’s a pragmatic guide to get to know the really essential tools for any writer. It’s called Minimal Writing on the Mac.
You can buy the book on various locations:
Since I’m trying to make a living of my work, it’d be awesome if you shared this with friends and on social media to support me and my writing.
Let’s go really basic: What is a Zettel? A Zettel is a note that is part of the archive of your Zettelkasten. You create it to contain knowledge for later use. The answer to “How do I compose a Zettel?” is simple: You form a Zettel in a manner that allows you the most efficient use even if another person would have to use it.
When you start with a Zettelkasten, you may feel hindered by the plethora of options. Paper or computer? Which application should I choose? Which categories should I create? (Hint: none) How many archives do I need for my projects? The short answer for the last question is: one.
I a recent radio interview, psychology graduate student Pam Mueller told the audience that taking notes of meetings or during class on your computer is a bad idea. You forget the things faster.
Plus you can’t sketch anything quickly when you’re using a computer.
Over the years at university, I adopted notes which were highly visual in style, not unlike Sketchnotes which I heard of many years later.
As we’re telling students in our coaching at my part-time job at university, it’s always better for your brain to add another layer of information: space, color, image, sound, smell, story. I think that’s why hand-written notes work better: you claim the space on paper in a unique manner. Even if you don’t add many visuals.
Using a computer or tablet or phone to type words requires you to be in a different mindset than writing with pen in hand. That’s why Sascha and I advise everyone to take reading notes on paper first. The gap between paper-based reading notes and the book or article you’re reading is smaller, even if you read on a digital device. Typing will always be more challenging, and switching back and forth will ruin your focus.
So take notes on paper, but write on your computer, since you’ll be about twice as fast to finish a first draft and produce more during the process.
I’ve made a lot of progress using Evernote for my term paper. As announced, I want to share the progress with you so you can see how things develop. Turns out, Evernote doesn’t offer publicizing of notebooks any more. Bummer. So I want to do two things today: share the details of the progress and invite you to the notebook privately.
A blog post called “Designing a Personal Knowledgebase” caught my attention today. In it, Alex tells us how he’s struggling. In his worflow, he extracts information and stores it in his note archive, but he can’t seem to make much use of it.
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. ↩
I released a book two weeks ago. It’s called “Exploring Mac App Development Strategies” and it’s available for $9.99 on Leanpub. Today, I want to share with you the process of its creation. The book “happened” in two weeks of me coding an example project to solve a particular problem I encountered. I decided to jot down lots of notes and write about my decision making. It took some more hours to edit the copy, and even longer to proof-read and typeset the whole thing, but in the end I finished the 107 pages in under 14 days. I think this was possible because I knew the topic rather well, and because I am able to sit down and write or code for many hours straight. I stay focused by taking breaks regularly every 25 minutes or so.
The first week of National Novel Writing Month will soon pass. For aspiring writers, this month-long challenge has its difficulties: if you lack the routine more experienced writers undoubtedly employ, reaching 50.000 words by the end of the month will become a tough ride when you are fueled by excitement only.
In my last post A Life-Long Writing Project on Writing – and My Anxiety I said that I wrote a (small) book on writing while researching it. In this post I’ll present the method which led to this book.
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.
Since I recently released the Word Counter for Mac, I have given more thought to the process of writing itself, especially since your comments on writing vs editing started to pour in. I count my words to increase my productivity as a writer. “But!”, people exclaimed, “How do you account for rewrites, deletions, and correcting grammar?” By dividing composing from revising.
It’s important to manage working time. Managing to-do lists is just one part of the equation to getting things done when it comes to immersive creative work where we need to make progress for a long time to complete the project. To ensure we make steady progress, we need to stay on track and handle interruptions and breaks well. A short Knowledge Cycle will help to get a full slice of work done multiple times a day, from research to writing. This will help staying afloat and not drown in tasks.
Brian Crain talked about increasing productivity by tracking progress. To have a continuous metric is both motivating and informative. I, too, buy into the saying that you can only improve what you measure. The corollary is: when you care about something, when you really commit to it, you have to do your best to track it and improve. Writing is one such skill. You become a writer by writing more, and you can shift your identity consciously to make this change stick.
There’s an interesting 8min talk by Brian Crain on optimizing productivity. Brian found tracking his progress useful: I learned that having a continuous metric is enormously motivating since it allows you to continually improve yourself. These small, continuous changes make a huge difference over time.
Nowadays, I write all of my texts in outlines. This post is no exception. I found this to be a game-changer when it comes to writing, so I thought I’d share the process. I start with a few broad strokes and go into detail, which equals using deeper levels of indentation. Every item in the outline is going to be a full sentence. This way, I can rearrange paragraphs sentence by sentence in my text editor. Most of the time, though, blog posts simply are too short to make much use of re-arranging their parts. I use this feature heavily in my book manuscript, though, and I found that research-laden posts benefit from an outline, too.
I am working hard on the “Building Blocks” chapter of the Zettelkasten book and I want to finish it first to show it to the public. It covers all parts of the toolkit. To sketch a structure and talk about its components, I need to get the requirements and implementation done before talking about workflow details. Today, I want to show you a birds-eye view of the overarching systems metaphor I’m using in the book.
I want to answer the question: Why are unique identifiers useful when you work with a Zettelkasten? The objective of a Zettelkasten note archive is to store notes and allow connections. Both are necessary to extend our mind and memory. As long as the software you use doesn’t provide any means to create links between notes, you have to come up with your own convention. Even if the software did provide such a mechanism, I’d suggest you think twice about relying on it: I want to evade vendor lock-in for my Zettelkasten, and I think you should, too. So let’s assume you don’t care about the software and create your own hyperlink scheme.
I used Editorially for some time now and me and my collaborators were getting accustomed to the platform. It was more convenient to use Editorially than sharing plain text files in Dropbox, especially when multiple people were involved.
Editorially wasn’t designed for people collaborating at the same time, unlike files in Google Drive, née Google Documents. Also, commenting was a rather finicky task in my eyes. I’m accustomed to using the keyboard only, while Editorially required use of the mouse cursor. But it worked, and it made sense for people not accustomed to plain text writing environments. Editorially connected us Markdown geeks with the rest of the world.
- Writeboard.com was shut down, too. It was a simpler tool, but it supported versioning. 37signals are re-structuring their business, so Writeboard.com had to go.
- Draft is well. This app is focused on getting editorial reviews for your drafts, see changes and integrate them into your document. I have to test it with friends some more until I can judge the service. Unlike Editorially, Draft doesn’t highlight Markdown syntax while you write. It has a ‘preview’ action, though.
- Authorea is alive and kicking, it’s backed by Harvard University, and it’s especially useful for larger projects: you can collaborate on articles or book manuscripts simultaneously, one section per person. Behind the scenes, Authorea creates one text file for each section. Since there’s no one big document file, you can restructure the document easily. It will only change the order of file references in a table-of-contents file. This is similar to Marked, mmd_merge, and the book format of Leanpub. It’ll cost you some money to create private projects, though. Authorea is designed for Open Science where you’re encouraged to let other people see and fork your articlesIt’s like GitHub for scientific articles – it even supports LaTeX!
- Open Source has lots of proof-of-concepts. collaborative-markdown may be one way to go. It works fine at the moment, though it isn’t polished at all. Maybe one will have to combine it with syntax highlighting editors like Ace just as the people at OakOutliner seem to do. Also, there’s things like OpenEtherpad.
It seems there’s enough Open Source technology available to create an online collaboration tool if Draft and Authorea won’t do the job.
Do you know of any other alternative?
So you are a knowledge worker? This means 90% of your work is about dealing with words. Blogger, writer, journalists – the biggest chunk of work is writing. “Writing” is just a short term for producing words. Let’s be clear: productivity equals your output, counted in words. It is writing itself that equals the 20% which get you 80% of the results. If you want to improve as a writer, writing more is your best lever. And more writing leads to a myriad of other benefits:
A Zettelkasten makes writing texts easy. It encourages you to prepare research and the most of your writing before you compile your first draft. This way you can focus on one task at a time and needn’t sweat about getting through. This works excruciatingly well with longer texts but it’s proven indispensable for any of my shorter writing projects, too.
Assuming you’re a writer or a thinker, why should you care about the way you take notes? If you want to think creatively and write original articles and books, you need to form associations in your mind effectively. Notes can help you with that if you adhere to a few basic principles. You can emulate communication processes with your own notes if you structure them in a certain manner. Notes can and should stimulate new associations and foster your creativity just like a good talk does.