Anyone who's created or consumed content long enough will eventually find a fork in the road, both equally well traveled by: Should we post continuous updates or do a big launch? Blog Updates or Digital Garden? "Today I Learned" or 10x Evergreen Skyscrapers? Do people want the journey or the destination?
I think we should do both. I've come to regard learning — the accumulation of knowledge — as simultaneously a discrete and a continuous process.
If the tools we use don't respect this duality, information is lost — either writing involves too much effort, or reading requires too much context. This has implications both for people who want to learn better, as well as content creators who want to transfer knowledge better.
Books, courses, and wikis are prime examples of discrete learning.
- The ideal wiki article is a complete introduction, history, and overview of a particular topic. Its value comes from being a reliable aggregate source of truth. The structure and sequencing of knowledge presented is often as valuable as the content itself. As evergreen content, effort spent on both creating and consuming it has a high return, because it is designed from the outset to have lasting relevance.
- However, long books, courses, and wikis are a lot of content to consume all at once and may never be finished. The scope may be so large that it is hard to keep up to date, particularly when the structure itself needs to change with the times.
Twitter, Discord, and Email Newsletters offer modes of continuous learning.
- The focus is on new content, and lack of structure allows maximum flexibility. Information is also bitesize and thus very consumable. Because of the realtime/live nature and randomness of quality, there is inbuilt variable reward which keeps us as addicted as BF Skinner's pigeons.
- However, the lack of historical context can leave beginners out of the loop, and even experts can fall prey to base rate neglect. News also has limited long term expected value due to the Lindy Effect, and therefore have a much lower signal to noise ratio. Finally, since major developments tend to spread out over time, there is often no one canonical link that you can send people to get up to speed — you "just had to be there".
I've only mentioned examples familiar to individual learners, but this duality also exists at a company level. Do you put all your company knowledge in Notion/Sharepoint (discrete) or Slack (continuous)? Do your docs offer a complete learning path (discrete) or do people also have to read your blog and support forums (continuous)?
I've already given away the analogy in the title, but this situation reminds me of the dual-slit experiment of quantum mechanics. Here's a quick one minute explainer:
Perhaps you're most familiar with this in the double split experiment:
I'm no expert myself but the version that works best for the analogy I'm going for sums it up like this:
- As the light/electron beam is in transit, it acts like a wave.
- As the light/electron beam is "observed"/hits the screen, it acts like a particle.
This all has very nice parallels to the process of learning. Sometimes we are picking up knowledge in a continuous stream, sometimes we just want a big quantum of knowledge all at once. The best forms of learning combine the two modes:
- If you learn in a continuous stream, it is useful to recap everything you learned in a post-mortem or retrospective. If you've gained a few years of experience, it's helpful to write down Things You Believe or write up the guide you wish you'd had.
- If you learned in a discrete block, it is useful to continue that education with continuous spaced repetition or involvement in an alumni community (many professions from finance to airline pilots even require this as "Continuing Education"!)
The Particle/Wave Duality Theory of Knowledge defines learning — the accumulation of knowledge — as simultaneously a discrete and a continuous process. There's no point picking a side. We learn best with both, so if you are a content creator or knowledge worker, you need a way to record both.
If knowledge tools don't respect this duality, users will be forced to do the work of duplicating knowledge, or lose it forever.
I'll motivate this with a personal example. I run the Coding Career Community in two places - Circle.so for my async knowledge base (discrete), and Discord for my live chat (continuous). Of course, both are more continuous places of engagement compared to the book they are focused on, which is the most discrete item of all in my hierarchy (discrete-ness is a spectrum!)
People might think me crazy for splitting my efforts in running two communities, instead of one. But I get active users in both and they rarely overlap:
- My Circle members are nominally bigger, but far less active and conversations can drag out over days. The primary means of engagement is by the weekly Thursday recap newsletter that gets automatically sent out.
- My Discord members are fewer, but more active and respond quickly to new posts. The primary means of engagement is in-app notifications, banking on the network effect of my members already being active in other Discords.
You can analyze this split in every dimension and still come up 50-50. Think about the new user experience, a critical moment for every community.
- A Discord user can say hi and immediately get the dopamine hit of a hi back. But they're not going to scroll up and read through the best hits of the community (pinning isn't very effective), so what they see is just completely randomly whatever is the topic of conversation that day.
- A Circle user doesn't even have to say hi, but can get immense value from the top/pinned post and become a fan right then. So I can pour in all my effort to make that top notch.
There's no clear cut right answer. Some users will prefer one extreme, some the other, and yet more will just want both. Yet I need to keep both up to date. What I do right now is peak do-things-that-don't-scale: I post continuous updates to Discord, and then once a week I sum up the best of what I find and manually cross-post it to Circle. Sometimes I find the occasional quality post on Circle, so I send it back to Discord (for sharing with the Discord natives), and to Twitter (for marketing).
So I'm paying the expensive cost of Particle/Wave Duality, because my tools currently don't recognize it. I could make a bot to do the two way sync between Discord and Circle, but what I'd really like is for this to just be built in in some way.
If you are developer-literate, I also think there are a couple alternative analogies you can use to solve this dual need:
- Change Data Capture (discrete → continuous): When you update a row in a database, there can be inbuilt functionality to send a notification of what changed (eg DynamoDB with Kinesis Data Streams). So people can read up a discrete state of information, then subscribe to the diffs. This is exactly how I use Notion at work, where I rely on email updates of diffs since it is impossible for me to stay on top of all the changes my coworkers are making by checking through each document individually.
- Materialized Views (continuous → discrete*)*: As you add, modify, or delete data, a separate "materialized view" auto updates and can always be referenced as the source of truth on all the changes that have happened to date. This is how Kanban boards and issue trackers work, by presenting a top down view of the status of work items moving through the engineering process.
What would Change Data Capture and Materialized Views look like for knowledge management tools, say a Second Brain, or a Blog?
Ultimately I think a lot about this in terms of the context of writing and other forms of content creation. As much as I've been talking about the preferred content consumption angle, the stakes are even higher for content creation:
- Discrete knowledge items like books and courses are most useful to learners because they present a comprehensive overview. However if it is such a big lift, it may never get done and you may be doing your learners a disservice by not contributing your voice.
- By the way, many people also treat blogposts like discrete items, taking months to draft it and to have it peer-reviewed like an academic journal. This is usually unsustainable and the blogging grinds to a halt, killed by its own process.
- Continuous knowledge items like tweets and chat conversations are far more digestible and easier to create. However, small low effort items out of context aren't all that valuable in themselves, and struggle to stand out and get traction compared to 10x Content that sells itself.
Ultimately I think you should try to do both. Prototype by making continuous knowledge items, but be aware that most people will never see your work there. So periodically you need to do "treasure collection" - go back through your continuous streams, and pick out the most promising threads to turn into bigger, discrete pieces. I wrote about one such journey of mine in Bottom Up Idea Exploration.
Those of you familiar with the literature of learning may find a parallel to JIT vs JIC modes of learning. You can loosely map JIT learning to discrete knowledge (have a book or wiki to look it up when you need it, but not before) and JIC learning to continuous knowledge (plug yourself in to a stream of knowledge and let serendipity guide you).
But the mapping isn't 1:1. You can use a book as JIC learning if you resolve to read it cover to cover, or JIT as a reference. You can use a Discord chat as JIT access to a knowledgeable community, or JIC as a passive observer.
It is very popular to deride JIC because that is something we are trained to do in school and it can prevent us from actually doing anything productive with that knowledge. That is definitely true and most people should try to be more JIT purely because they naturally skew JIC. However that isn't to say that JIC has no place in learning - having a good mental map of everything is actually important to knowing what you don't know.
"Our team currently has years of docs in a Google docs like system. Main problem with new hires is that they haven't yet accepted that the docs are poorly maintained, or there are 6 docs for the same process written by different people and not deleted or updated. It's madness. How would you go about this process?"
Ah, the outdated knowledge base problem. We continually swing back and forth between wanting a discrete source of truth, but then time passes and continuous updates do not get registered. Technology hasn't (yet) solved this — although graph database tooling like Roam Research or Obsidian can automatically propagate continuous updates to discrete materialized views, it is still a poor susbstitute for properly curated and updated structure.
Ultimately I view the knowledge base problem as a human problem - you have to commit to maintaining your sources of truth, but don't make it so huge as to be unmaintainable and unreadable. Don't be so rigid about your process that you treat people talking to each other to figure out problems as a bug. Identify what you care about and make it a priority to enforce that, but recognize that enforcement isn't free and pick your battles.