I brought a spiral-bound notebook to a system architecture review last week. Eight engineers with laptops open, shared Miro boards, Notion docs tabbed and ready. And me, with a mechanical pencil and a Field Notes memo book. One colleague glanced over and half-smiled — the kind of smile you give someone who shows up to a video call with a landline phone.
By the end of the meeting, three people asked to photograph my pages.
That's the thing about writing by hand. It doesn't scale. It doesn't sync. You can't search it, share it in Slack, or autogenerate tickets from it. And yet, consistently, the people who write things down by hand seem to understand systems better than those who don't.
The Slow Medium
There's a body of research (Mueller and Oppenheimer, 2014, most famously) suggesting that handwriting engages different cognitive processes than typing. When you type, you can transcribe nearly verbatim. When you write by hand, you can't — your hand is too slow. So your brain has to do something it doesn't do when typing: it has to compress, summarize, and decide what matters in real time.
For architecture discussions, this forced compression is exactly what you need. You can't write down every microservice name, every API endpoint, every edge case. So you draw the boxes that matter. You draw the arrows that carry weight. And the act of deciding what to leave out is itself a form of architectural thinking.
"The diagram that leaves things out is more useful than the diagram that includes everything. The first is a model. The second is a mirror."
— scribbled in the margin of my 2024 notebook
What My Notebook Pages Actually Look Like
I'm not an artist. My diagrams wouldn't win any Miro template awards. But they have a quality that digital diagrams often lack: uncertainty is visible. A confident box with a clean border means "I understand this component." A squiggly, barely-there oval means "something lives here but I'm not sure what yet." A line with a question mark means "this dependency might exist, or it might be my misunderstanding."
Digital tools don't have a visual vocabulary for uncertainty. Every box in Lucidchart looks equally confident. Every arrow in draw.io implies the same level of certainty. But in a notebook, the weight of your pencil stroke is metadata.
The Practice
Here's my actual workflow. It's not complicated, and I'm not precious about it.
Before the meeting: I write the date and a one-line purpose at the top of a fresh page. That's it. No agenda, no prep notes. I want to arrive ready to listen, not ready to confirm what I already think.
During the meeting: I listen more than I write. When someone describes
a component, I draw a box. When someone describes an interaction, I draw an arrow. When
someone says something I want to push back on, I put a ? in the margin.
When someone says something genuinely insightful, I put a !.
After the meeting: This is where the magic happens. I spend 10 minutes — just 10 minutes — reviewing my pages. I add annotations. I circle the things that still confuse me. I draw a cleaner version of any diagram that matters. And I write one sentence at the bottom: "The thing I didn't understand is ___."
Translating to Digital
"But Fred, what happens when you need to share those notes?" Fair question. Here's my answer: most meeting notes don't need to be shared. The value was in the thinking, not the artifact. But when they do — when the architecture sketch becomes a design document — I translate by hand into structured text.
# Auth Service Integration
## Status: RFC (Request for Comments)
## Date: 2026-02-14
### Overview
API Gateway validates JWTs issued by Auth Service.
Data Service trusts gateway-forwarded claims.
### Open Questions
- Cache layer between gateway and auth?
- Evaluate Redis vs. in-memory LRU
- Must handle token revocation
- Connection pooling strategy for Postgres
- Currently: default pg-pool settings
- Need: benchmarks under concurrent load
### Decision Needed
Who owns the cache invalidation logic?
Auth Service team says gateway. Gateway team says auth.
(This is where the actual architecture lives.)That translation step — from messy notebook to structured document — is itself a form of thinking. It's where I catch the gaps. "Wait, I drew an arrow from the gateway to the cache, but who populates the cache in the first place?" The notebook surfaces the questions. The document forces the answers.
The Tools, Since You'll Ask
I'm not particular about the notebook. Currently rotating between a few:
- Field Notes Pitch Black — for daily carry. Dot grid. Fits in a back pocket.
- Leuchtturm1917 A5 — for longer sessions. The numbered pages and index are genuinely useful.
- Rhodia No. 16 — when I want that smooth French paper feel. Better for fountain pen days.
The pencil is a Pentel P205, which I've used since college. It's $4 and better than any $40 pencil I've tried. For pens, a Pilot Metropolitan with Iroshizuku shin-kai (deep sea) ink, because life's too short for boring ink colors.
On the Code Side
For the digital translation, I keep things simple. Markdown files in a docs-*
repository, tracked in git alongside the code they describe. No Confluence, no Notion,
no wiki. Just plain text that lives where the engineers already look.
project-root/
docs/
architecture/
2026-02-14-auth-integration.md
2026-01-30-cache-strategy.md
decisions/
adr-001-jwt-validation.md
adr-002-connection-pooling.md
src/
...Architecture Decision Records (ADRs) deserve their own field note. The short version: they're the closest digital equivalent to a notebook margin annotation. A short document that says "We decided X because Y, and we considered Z." Future-you will thank present-you.
Why This Matters More Than You Think
I've been writing software for over twenty years. In that time, I've watched the industry chase every productivity tool imaginable. Jira boards, Notion databases, Miro boards, AI-powered documentation generators. Each one promises to externalize your thinking so your brain can focus on "higher-level" concerns.
But here's what I've observed: the developers who understand systems most deeply are the ones who spend time thinking slowly. Not the ones with the most elaborate tooling. Not the ones who can navigate Confluence fastest. The ones who sit with a problem, turn it over, and resist the urge to jump to implementation.
A notebook doesn't make you smarter. But it makes you slower, and sometimes, slower is exactly what the problem needed.
If you try this and it changes how you think about a system,
I'd love to hear about it.