Automations, Time spent in the environment, "And then what?"
Yesterday I was musing on automations for note-taking tools and I was struck by the idea that automations in our tools can go too far. It seems there is some amount of desirable friction in working with our tools that changes the tool and our selves for the better.
As sometimes happens, these musings took the form of a poorly-worded tweet that was understandably misunderstood:
https://twitter.com/jessmartin/status/1517233384585674756
Favor automations that encourage time spent in the resulting environment
Can an automation go too far?
An automation is simply something being done for me that I don't have to do myself. Consider another example of a tool-user and their environment: a woodworker and their workshop. My neighbor is retired and now spends much of his time building things in his woodshop. I've made extensive use of his shop and tools on many projects over the years, and I wanted to express my gratitude. His shop is a bit of a cluttered mess, so I offered to clean it up for him. "No no, I'll clean it up myself one of these days," he replied, firmly. I didn't understand his answer at the time, and, selfishly, I would have appreciated the shop being cleaner for the times when I had to use it.
But looking back, there's something intuitively right about a woodworker cleaning their own shop. Cleaning the shop is a productive use of "time spent in the resulting environment" that sharpens the woodworkers' familiarity with that very environment. For starters, they ensure that everything was put in the correct place; they know where their tools and materials are when it comes time to use them.
But furthermore, a workshop is a highly malleable environment. It's often in the process of "cleaning it up" that we notice the possibility of small ergonomic improvements: mount that vise over here rather than over there, slide the tablesaw a bit to the right lets wider lumber more easily clear the double doors, etc. Cleaning up the environment blends smoothly into adapting the environment for our use.
This leads me to a principle: favor workflows that encourage time spent in the environment.
Notice that this conclusion is actually about workflows, not strictly automations. I use some automations in my current note-taking workflow. For example, I have scripts that export my notes from Bear, clean them up, and build an Andy Matuschak sliding-panes style lab notebook. I've automated much of that workflow, and intend to automate more. And when I consider that automation in light of my new principle the automation is actually quite helpful. I built a sliding-panes style site for my own usage because I find it a more usable way to browse my own notes than the native UI of Bear. I use Bear for writing, my own site for reading. Automation saves me the drudgery in manually copying notes to the site, which allows me to spend more time exploring my own notes.
The original automation which triggered my tweet was a Readwise to Roam integration. The integration automatically copies highlights from Readwise into Roam, creating a new book or article note if there isn't already one, and creating an entry in your Daily Notes. This all happens behind the scenes, without any effort. Wonderful, right? Considered against this new principle, this workflow isolated from other workflows does not encourage time spent in the environment. In fact, you could be reading in Readwise every day, open your Roam after a few weeks, and find it cluttered with quotes, book notes, and daily entries. Has that fostered time spent in the environment?
The workshop analogy may be useful again here: that would be similar to coming out to your workshop one day and finding piles of wood and screws neatly stacked in the middle of your shop. If you don't have a plan for what to do with that wood, this "free gift" is actually clutter that you now have to find space to store. (Don't get me wrong, as a woodworker myself, I don't turn down free wood. Drop it off at my shop any time!)
But this raises an even more important question that we should be asking, about our automations and all of our workflows: I've taken all of these notes and captured all these quotes (gathered all of these materials). And then what?
"And then what?"
The other day, I recommended a podcast interview with Andy Matuschak to a friend. Around 21:08, Andy interrogates the practice by which one develops an idea over time using a note-taking practice. My friend reflected on their time spent with Obsidian with some chagrin:
Andy's question "and then what?" haunts me every month as I see the the raw number of Obsidian notes increase, but the links between notes stay static. I even put a category in my bullet journal labelled "zk" to try and instill a habit of taking a little time every day to refactor and link notes... I am cursed because most of the knowledge capture I have in my personal zettlekasten is stuck in those g*dd4mn nice to have Daily Notes.
This has become something of a refrain in the tools for thought world:
https://twitter.com/fortelabs/status/1516711338957017090
Or, as Brian Sholis puts it:
https://twitter.com/briansholis/status/1517241031779143680
I'm not certain we're taking the ramifications of this rhetoric seriously enough yet. Stop for a moment and ask yourself why are you taking notes at all?
I've given this question some thought and have come up with a few answers for myself. I'm researching how computers can be more expressive tools for humanity. My knowledge tools help me in three ways:
- Increasing the rate at which I learn and utilize new information. I have found that writing about a topic sharpens my thinking on that topic, illuminating gaps, solidifying specific concepts. As I've shifted my focus to research into better computers, I've found that there are a lot of things I need to learn and my note-making practice seems to help with that.
- Improving collaboration with others. By writing coherent notes about topics, I've found that I have written artifacts that I can share with others. These artifacts often lead to more fruitful conversation and collaboration.
- Triggering "interesting inbounds." Writing notes and publishing them, whether through my weekly newsletter or my Lab Notebook, has sparked some really interesting conversations and interactions which have helped me further develop my thinking, find research projects I was unaware of, and generally make friends on this journey.
When considering an automation of your knowledge tools, consider whether it moves you closer to your own goals. Always ask of the automation: and then what?
Most often, this will mean that an automation needs to be coupled to one or more workflows that will help you do something with the results of that automation.
As Linus put it in response to my tweet:
If you want to use knowledge, you should use workflows that feed those back to you in some way, whether by manual re-encounters or automated re-surfacing.
Glimpses of the Future
Next week's Tools for Thought Rocks meeting promises to be interesting. (April 28 @ 9am PT, register here). Maggie Appleton is going to be speaking on tools for thought as cultural systems, not computational objects. Hunter Clarke will be sharing a novel user interface for problem decomposition and task completion. You should come hang out.
"Software interfaces undervalue peripheral vision." A fascinating twitter thread by Andy Matuschak exploring how our software interfaces could be better structured to "spontaneously prompt action." I'm trying a few experiments in my office to add ambient information at the periphery that will hopefully lead to the kind of actions that I want to take. I'm trying to design my environment to make it easier for me to accomplish my goals, with less will-power.