28
The Particle/Wave Duality Theory of Knowledge
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.
Twitter, Discord, and Email Newsletters offer modes of continuous learning.
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:
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:
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:
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.
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:
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:
- 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.
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.
28