Category Archives: Writing

Recommendation: Digital Zettelkasten by David Kadavy

I just bought and finished reading Digital Zettelkasten [amazon affiliate link] by David Kadavy. It’s a quick read and a good companion to How to Take Smart Notes [amazon affiliate link], which I talked about in Write While True Episode 2: Small Bits of Writing and Write While True Episode 3: First Drafts.

Like David, I think of note-taking as primarily about writing and is the starting point of my original writing. His book covers his workflow, which is a lot like mine. I got a few new tips, but it was mostly a reinforcement of how I think of note-taking.

As I covered in my podcast, I “read” by writing. At the end of reading a book, I have generated bits of writing in Obsidian and flash cards for Anki (covered in Write While True Episode 14: Spaced Repetition). This has helped me retain the information I have read, have new ideas, and develop them into new writing.

If you write, but don’t currently have a note-taking practice and would like to see how one writer does it (in detail), this book is worth your time.

Building a Serendipity Machine

In yesterday’s podcast, I talked about spaced-repetition and how I use Anki to help with my memory. Anki is a flash card system that uses algorithms to show you cards just as you might be forgetting them.

If you are just using this casually, like I am, you only need to “study” for a few minutes a day (and skipping days or even weeks will be fine—Anki will catch you up). If you are a student who is using Anki to cram for exams, you would probably do it differently.

I built up my deck over time. I make new cards while reading or watching videos. I made a bunch last week while watching WWDC.

In the podcast, I said to use a single deck with all of your cards mixed together. So, if in a few months, you read books in different subjects, you wouldn’t make separate decks for each book or subject. This makes it a lot easier to just make cards whenever you want without thinking about it too much. It also makes studying a kind of serendipity machine.

A couple of episodes ago, I had spoken about how to generate ideas by combining disparate knowledge. Going through an Anki session of uncategorized cards helps me do that regularly.

So, in my deck today, I was asked about:

  • The kinds of gates you find in QUIL quantum computing (I read Quantum Country this year which is a book with embedded spaced-repetition)
  • The goals of visual design
  • A specific Typescript operator
  • Covey’s 7 Habits
  • The parts of C4

As I think it over, there is perhaps something interesting about the communication principles in C4, the communication goals of visual design generally, and Covey’s 7 Habits—specifically “Seek First to Understand”, which is the core communication habit.

I should write a note about that.

Design by Comparing Opposites

In my podcast episode, Write While True Episode 7: Find Your Voice, I tried to express an idea that I find is useful in a lot of contexts. There are some choices where you are trying to make something specific or differentiating—in those cases, one way to know that you’ve done it is to see if the opposite choice is also reasonable.

In this case, I was talking about trying to find my “voice” in the podcast—what makes it mine and not generic. I recommended Joanna Wiebe’s video on voice and tone.

But, I cautioned against a voice that was “smart”. I said:

I actually don’t think smart is a good choice because the opposite of smart is very rarely appropriate. Everyone would choose to sound smart.

When you have a generically positive aspect that you want (like smart), a useful technique is to consider opposing ways to achieve it.

I recommended considering the choices of “expert” or “fellow learner” instead of smart. Both voices might be smart, but they are specific, opposite, and both are reasonable.

This is also a good technique in job seeking. It’s easier to find what you want if it’s not something that everyone would claim to have.

Sending a clear signal that “this is not for you” is the only way the people that it is for will recognize it.

Observing Experts

I started running in 2005 and did a marathon in 2009, but I ran sporadically for a few years after that. I had always done it pretty much on my own, and that limited my progress and sometimes led to injuries.

I started running seriously again in November 2018. The big change I made was getting a coach. I had just read Peak [amazon affiliate link] by Anders Ericsson, and learned that one way to become an expert was by watching experts. It wasn’t so much what the expert taught—Ericsson thinks that experts don’t always know why or how they do things. What seemed to be useful was just observing experts. (Incidentally, Ericsson is also the source of the 10,000 hours idea popularized by Malcolm Gladwell. Peak corrects a lot of the misconceptions about that).

My running coach, Holly, has run her whole life. She’s done 25+ marathons and several triathlons and also uses coaches herself. She often expresses her lessons as her observations of the elites she was run with (so I am observing an observer). Two years into it, I have gotten everything I wanted out of it and more.

So, I am trying to apply the success I have had by running with an expert to other aspects of my life.

I want to write a lot more, so I joined the Blogging for Devs pro community where I am surrounded by devs of all success levels that I can observe. Last year, I did the Akimbo Podcast Workshop which similarly exposes you to a cohort of podcasters—a mix of experts and other learners. I am learning a lot just by watching and emulating their behaviors.

The recurring behavior I observed from the successful bloggers and podcasters in these communities is to just publish. Almost everything else there is to learn only makes sense in the context published work.

So, my advice is to seek out experts doing the thing you want to be an expert in. And when you find one, I’d ask just to watch them work and then emulate their behaviors without necessarily understanding why at first. The book, Peak [amazon affiliate link], has a lot to say about this, and if you are skeptical, watch this video about learning tennis by observing.

March 2021 Blog Review

This month I released a podcast. I believe that a podcast can be a companion to another activity. I had thought that I could come up with something related to coding, but that was too hard to do without visuals.

So, I decided to try a writing program for programmers. Write While True is a podcast that helps programmers establish a writing habit. Each episode is around 10 minutes, and you are meant to do the writing exercise it describes as soon as the podcast is done.

If you are finding this post way after March 2021, and you are interested, I recommend listening to the first few episodes. They are foundational and meant to be evergreen. If you are a programer that writes publicly and has some tips, get in touch, because I’m going to have guests at some point.

I’m proud that my process makes my podcast accessible.

I’m thinking a lot about Excel. I have seen a lot of non-programmers make incredible things with it. I wrote Excel is Programming and Excel as a Programming Language with my nascent thoughts on that. I plan to write more about this.

I had a lot of random pieces related to software development:

Yesterday, I wrote about sonifications, which are the sound equivalent of visualizations. I’ll have a lot more to say about that in April.

Call for Write While True Podcast Guests

A couple of weeks ago, I launched Write While True, which is a writing program for programmers (in the sense of a training program). The core episodes will be short descriptions of writing exercises that will get you writing.

But, I do think it would be good to have guests.

In a guest segment, I do want to eventually get to some actionable advice, and I think it would help if the guest wrote regularly somewhere, since the core thesis is that the podcast will help you write more.

If you are a programmer, then it’s fine if that writing is on a blog, but if you are not a programmer, then I would prefer that you are a professional writer of some sort.

If this sounds like you, get in touch.

Trying to Tell Stories

My instinct in writing is to just say what I believe to be a true or interesting in a direct way. Maybe give an argument or two why and call it day.

So, most of what I write is kind of like this: “Hey everybody, I think blah blah blah and one time I blah blah blah’ed and yada yada yada, it was great. You should blah blah blah too.”

And even as I’m doing this and re-reading my writing, I am thinking: “this is kind of boring”, but I didn’t know how to make it better. So I’ve plugged along because up to this point, I’ve decided that writing imperfectly is better than not writing.

But, today, (March 5th, the day I am writing this), is my first day as an independent software developer, writer, or whatever I end up doing. I don’t have the safety net of gainful employment to give my work meaning. It somehow has to come from me and my own projects.

And this blog is one of those projects, so it’s not enough to just write any more. Eventually, this blog has to be good, which I define as valuable to readers (as opposed to just valuable to me as a place to practice writing).

Over the years, I have seen/read/heard a lot of advice about writing, but one really stands out to me right now, and I am trying to really understand it.

It was a podcast episode of Scriptnotes (transcript), where Craig Mazin, the writer of the Chernobyl mini-series, explained what a story is. I recommend reading the whole thing, but the essential generator of story was an argument. This interests me because most of what I am writing is my side of an argument.

According to Mazin, to generate a story, you start with an argument with a true side and a false side. Then, you create a character that believes the false side and lives a stable, but imperfect life with this belief.

The story will make that stable life impossible and eventually change the character’s worldview such that they act in accordance with the true side of the argument. The details are fascinating, and I recommend you read the transcript (the back episodes are available on a paid subscription if you want to listen to it).

One way to sum it up is:

What is more interesting: “you know, if you lie to people, they might not believe you when you are telling the truth” or The Boy who Cried Wolf?

The first example is just advice (which is actually good advice, but it’s boring) and the second is a story. It has humor, it has twists, and it has an argument exemplified by a character living the opposite of the advice. It’s not exactly the same structure as Mazin’s, but it works.

Craig Mazin writes fiction, and a lot of what he’s describing is story invention. But, it applies to non-fiction as well (see his José Fernandez example). And, of course, if I think back to interesting non-fiction books I have read, they are full of stories.

But, I also know that long-winded stories (when you want actionable advice) are somewhat off-putting to me. I personally need to find the right balance.

In my own journey of “Stating advice directly, but in a somewhat boring way” to “Telling an interesting story that incidentally makes my argument”, I am really just getting started, but I will try to tell more stories of characters living the false and true sides of arguments I am making rather than just plain descriptions of the argument.

Accessibility First in Podcasts

I released a podcast a few days ago. I am doing this podcast partly to improve my writing and my ability to do Professional Performances, so it is scripted.

A side benefit is that it doesn’t take much to produce a transcript. In fact, I have a pretty good one before the podcast is even recorded.

Aside from accessibility, transcripts have many other benefits. SEO is a big one, but also, it makes it a lot easier for listeners to refer back to. And if they feel inclined to quote you on social media, it makes it a lot easier.

In any case, I’m glad that my process produces the accessible artifact first.

New Podcast: Write While True

One thing that I like about podcasts is that you can do them while you are doing other things. But, I think there’s an opportunity for a podcast to augment the other thing you are doing.

Write While True is a podcast is for programmers that want to write more. Listen to it and get ready to start writing when it’s done. Each episode is short and will describe a writing exercise you can do when it’s over.

The first episode is an exercise that will help you get unblocked.

Subscribe to get more episodes.

Writing vs. Thinking About Writing

In my review of The Practice, I said that I was posting every day to focus myself on writing something worth posting every day. Shipping makes me think about a reader more than journaling would.

But, I am definitely not worrying too much about quality because I believe that that will come with time.

This story from Art & Fear [amazon affiliate link] is often cited to illustrate the power of quantity. I heard it first from Coding Horror in 2008, but here’s the earliest reference I could find:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

[…] Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work – and learning from their mistakes – the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

When I think back to how I learned programming, I remember that I did it nearly every day and produced a lot of code. Most of it was unshippable, but I learned from making it and eventually learned to ship it too.

I believe in combining identities to build a new skill from a developed one, so applying my code writing attitude to writing text will help me keep going. I have seen the power of quantity work before.

I have also seen the effect of “theorizing about writing”. I have been trying to write more for years. I started this blog in 2003, and right now, just two months into 2021, I have more posts than any other single year.

Thinking about writing produced very little. Please, don’t wait eighteen years to learn this lesson.