More than just taking notes - Learning exhaust

TL;DR

Treat notes as byproducts of learning; the real target is understanding that can be applied.

Briefing Cornell Notes

Briefing

Learning notes as “learning exhaust” is the through-line: notes aren’t the goal, they’re the byproduct of turning an idea into understanding and then applying it. The process described starts with a book that sparks curiosity—Steven Johnson’s *Emergence*—and ends with multiple, reusable outputs: public Obsidian notes, applied frameworks for different domains, and conference-ready slides built from the same knowledge base.

After attending the first cohort of a visual thinking workshop run by Zsolt Viczián, the author’s cohort book became *Emergence*. The attraction was immediate, but so was the fear of losing momentum without a future obligation. That motivation pushed the learning forward in a concrete way: applying to speak at a conference about *Emergence*—specifically “emergent load testing,” a work-adjacent topic. The learning cycle then unfolded across months and iterations.

The book was read twice (November and again in February) to reprocess sections that weren’t retained and to revisit notes from the first pass. Highlights were captured through two channels. Standard highlights flowed from Readwise into Obsidian via Kindle highlights, while a Kindle Scribe added handwritten notes and doodles that couldn’t be sent directly into Readwise. Those Scribe artifacts were stored as a PDF in Obsidian, then carried forward into later stages via screenshots and manual transfer. A key detail: doodling happened early—before fully finishing the book—so visualization became part of comprehension rather than a late-stage activity.

From there, the author built a layered note system. A long “book note” summarized Johnson’s points in the author’s own words, using a thesis/antithesis/synthesis structure. The thesis section identified criteria that facilitate emergence (including ideas like bottom-up approaches and “emergent software”), while the antithesis section challenged weaknesses—such as emergence being indistinguishable from chaos, taking too long to become useful, or being too unpredictable. The synthesis then explored when emergence beats its opposite, framed as a reductionist hierarchy.

Next came an “abstracted note” that stripped away biology-specific context so the factors facilitating emergence could be generalized. The author added concepts in their own vocabulary (including agency and federated communication) and separated disadvantages into a dedicated note. The idea then “spidered out” into applied domains: emergence in tech (including emergent software), emergence in play, and community-driven emergence through learning in public.

The applied work culminated in two practical outputs. One focused on “emergent load testing,” translating emergence into a testing mindset that ranges across code styles (imperative, declarative, generative) and ties generative load testing to application affordances. The other focused on “emergent note-taking,” connecting emergence to Zettelkasten and atomic notes, and producing a scripted video task note.

Throughout, the author treated publishing and iteration as part of learning exhaust: notes were shared on Obsidian Publish, slides were exported as HTML and posted publicly for feedback, and even changes to the knowledge base were tracked via a Changelog approach using a Vault Changelog plugin (with a fork to support excluded paths). The payoff wasn’t just better notes—it was sustained motivation, faster refinement through public review, and a system where learning, application, and publishing feed each other.

Cornell Notes

The core idea is to treat notes as “learning exhaust”: useful outputs that appear while someone turns an idea into understanding and then applies it. Using Steven Johnson’s *Emergence* as a case study, the author reads the book twice, captures highlights through Readwise and handwritten/doodled notes via Kindle Scribe, and stores everything in Obsidian. The notes progress from a detailed book summary (thesis/antithesis/synthesis) to an abstracted, more general framework, then into applied notes for “emergent load testing” and “emergent note-taking.” Publishing and iteration—posting drafts, exporting slides, and tracking changes via a changelog—help keep the learning process active and relevant.

Why does the author treat notes as “learning exhaust,” and how does that change what gets created?

Notes are framed as byproducts of acquiring understanding, not the endpoint. That mindset drives a workflow where reading leads to public book notes, then to abstractions in the author’s own language, and finally to applications in other domains (load testing and note-taking). The system is designed so comprehension becomes actionable—otherwise the learning stays “not really gonna be relevant” for the author.

What concrete steps turn a book highlight into an applied framework?

The process starts with capturing highlights (Readwise → Obsidian) and handwritten/doodle notes (Kindle Scribe → PDF in Obsidian). Then the author builds a “book note” using thesis/antithesis/synthesis: criteria that facilitate emergence, weaknesses (e.g., emergence as chaos, unpredictability, usefulness timing), and a synthesis about when emergence is better than a reductionist hierarchy. Finally, an “abstracted note” generalizes the facilitating factors and adds concepts in the author’s vocabulary, which then feeds applied notes like emergent load testing.

How did the author use doodling differently than a typical “visualize later” approach?

Doodles and handwritten notes were created while reading, not after finishing. The Kindle Scribe’s ability to handwrite and draw in a note-like way enabled visualization before the book was fully processed. Because those artifacts couldn’t be sent to Readwise, the author stored them as a PDF in Obsidian and used screenshots to carry them into later stages.

What role did public accountability and feedback play in the learning timeline?

A workshop cohort sparked the initial reading of *Emergence*, but applying to speak at a conference created a deadline that restarted and sustained processing. The author then posted drafts publicly (Mastodon) and shared slide exports for review. Later, feedback led to visible slide updates, and followers noticed the changes—turning public learning into an iterative loop rather than a one-time capture.

How does “emergence” get translated into load testing specifically?

The applied note on emergent load testing connects emergence to how testing might shift across code paradigms (imperative, declarative, generative). It also frames generative load testing in terms of application affordances—what the application makes possible—while pulling in ideas from other notes in the vault to support the translation.

What does the author mean by tracking knowledge work with a changelog?

Instead of only storing finished notes, the author publishes a changelog of recent note modifications. Using a Vault Changelog plugin (with a fork to support excluded paths), the author shares the last 300 significantly changed notes while filtering out irrelevant categories (like role-playing games). The goal is to see what currently occupies attention and how thinking evolves over time.

Review Questions

How does the thesis/antithesis/synthesis structure help convert a book’s claims into a reusable framework?
What specific limitations of Kindle Scribe shaped the author’s workflow, and how were those limitations handled in Obsidian?
In what ways do public posting and conference deadlines function as “learning exhaust” accelerators rather than distractions?

Key Points

1
Treat notes as byproducts of learning; the real target is understanding that can be applied.
2
Create an obligation or deadline (e.g., a conference talk) to prevent promising ideas from stalling after reading.
3
Capture information through multiple input modes (Readwise highlights plus Kindle Scribe handwritten/doodles) and store them consistently in Obsidian.
4
Move from book-level comprehension to abstraction by rewriting in your own language and generalizing context-specific factors.
5
Use structured critique (thesis/antithesis) to surface weaknesses, then reconcile them in a synthesis that defines when the idea works best.
6
Apply the abstract idea to multiple domains to keep it relevant—here, emergent load testing and emergent note-taking.
7
Publish and iterate: share drafts publicly, export slides for feedback, and track changes with a changelog to make learning visible over time.

Highlights

Notes are framed as “learning exhaust”—the useful residue of turning curiosity into understanding and application.

Early doodling during reading (via Kindle Scribe) helped visualization happen before full comprehension, not after.

A thesis/antithesis/synthesis book note became an abstracted framework that then “spidered out” into tech, play, and community learning.

Slides were exported as HTML and posted for review, enabling visible iteration based on feedback.

A changelog approach (Vault Changelog with a fork) turns evolving thinking into a trackable, publishable artifact.

Topics

Learning Exhaust
Emergence Framework
Obsidian Workflow
Emergent Load Testing
Emergent Note-Taking