In this essay, he talks about the amazing work of Edwards Deming, specifically the PDSA model.
PLAN
DO
STUDY
ACT
It's a model for continuous improvement by iterating through multiple workflows to achieve desired results through trial & error (honest examination of results).
The idea of PDSA is that it involves multiple loops of PDSA.
Rarely in life do we reach our intended goals with just one attempt, rather we succeed over multiple iterations, with each iteration getting closer to the desired result.
In this article, Cedric calls our attention to one sad reality. While it is easy to plan and get started (Plan, Do), we often fail to do the Study (analyze their results) and Act (adjust our approach).
He encourages us to "finish the loop" even if it seems like it won't succeed.
Finishing the loop allows us to fully gather the information we need so that we can adjust our workflow and then try another loop.
In other words, what lessons were learned in the current loop to feed into the next loop.
Why is this relevant for TfT? We rarely find the perfect worklfow or approach to some problem we want to solve on our first attempt.
Rather we need to define the goal and then start multiple loops of testing our theories until it finally succeeds.
Let me give you an example.
EXAMPLE: I have to read a lot of material for work. The problem is time.
How do I not only get through all the reading material but extract useful "things" from that material? I mean, what is the point of reading if you don't benefit from it?
I started a series of PDSA loops to experiment with improving "value-based" reading.
For example, how do I select what is relevant and important?
How much time do I spend reading each topic?
How much time a day can I read?
These are not easy answers to these questions.
So I started with a list of priority topics and non-priority topics.
Week one, I had 4 priority topics, and I read 5 minutes on each topic each day (20 minutes reading)
I did these loops over multiple months, increasing and decreasing time, the number of things to read, and so on.
Each loop was a week so that I could iterate the process fast.
As I went through each loop, I documented the plan and, during the study phase, "the results".
Then I adapted to what I learned for the next cycle.
It is a painful process, but slowly I started to see how much I needed to read daily to get measurable value from my reading (also to enjoy it and not hate it)
I gathered many interesting insights on myself.
So, the lesson is, PDSA is a useful tool for getting your TfT system optimized, but its a serious investment. My advice:
1) Determine the big problems you need to solve 2) Try PDSA loops on the problem 3) Stick with it until you have resolved the problem.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Do you use YAML in your notes? (frontmatter or inline fields)
Do you like YAML?
What do you dislike about YAML?
YAML is cumbersome to work with but does add a "database" like layer to our notes. #TfT
2/5 While I don't find YAML hard to work with, it does create a fair amount of "busy" work in Obsidian. This si one of the appeals to me of a tool like Tana, which provides more UI for quickly working with schema and inputting data.
3/5 On the other hand, Markdown is not a database and doesn't have a way of capturing schema like information. This is why some tools like Obsidian have added a "schema" layer.
1/ In the spirit of sharing, here is my folder structure.
I keep things shallow for "active" documents. I only keep active notes and projects on the root. That way, they are super easy to get to. I archive them once done to prevent the structure from becoming overwhelming. #TfT
2/ I have built plugins for many Tools for Thought. Obsidian, Craft, Roam, Readwise & Office (Excel, Word, SharePoint -- if you consider them to be TfT).
This opens doors to meeting many wonderful users and developers of Tools for Thought. I learn so much from each conversation.
3/ Many of us use plugins for our tools and don't think much about the effort that goes into them. We know there is a lot of effort, but we know we don't really know.
Man, I hate that expression. While this term has its place, somehow, in the #TfT space, it has become a way to throw mud at others. (competitors, jealousy, etc).
Tana is not a shiny object. Their Slack is proof something good is cooking.
2/ I did not record any official numbers, but before their early access announcement, I am sure slack was sitting around 200-300 users. As of today, it is 3000+.
That is a significant and overwhelming increase in just a matter of a few weeks.
3/ In the introduce-yourself channel on their Slack, numerous new people introduce themselves daily.
These are amazing, smart, sincere & exciting people.
They want to be a part of something special. I applaud them for investing time and energy in Tana's early development.
2/ Obsidian and Tana are not easy to compare. They are in the same competitive space: Tools for Thought, but they solve different problems. So there is overlap, but they are fairly different.
Obsidian is the best choice for Markdown, TNO, and long-form writing. Single-user work.
3/ Tana will be best for outliner database-like functionality: (everything is a database record). So stronger for more structured content and querying against that. Multi-user collaboration.
Tana solves many problems within the product that other TfT tools need plugins for.