Why the Best Developers Still Use Pen and Paper

There is a notebook on my desk. It is cheap, spiral-bound, and has coffee stains on the cover. The pages are filled with messy diagrams, half-finished pseudocode, and arrows pointing in directions that only make sense to me. My British lilac cat, Luna, has chewed on one corner. It is, without exaggeration, the most important tool I own as a developer.

I say this as someone who has spent the last decade surrounded by screens. I have three monitors. I use an AI coding assistant daily. My IDE has more extensions than I can count. And yet, when I hit a genuinely hard problem — the kind that makes you stare at a blinking cursor for twenty minutes — I reach for a pen.

This is not nostalgia. This is not some performative Luddism designed to make me look thoughtful in a coworking space. This is a deliberate, evidence-backed practice that the best developers I know share. And the reasons behind it are more interesting than you might expect.

The Quiet Crisis of Digital-Only Thinking

Something has shifted in the last few years. The tools we use to write software have become extraordinarily powerful. Cloud IDEs spin up entire development environments in seconds. AI assistants can generate boilerplate, suggest fixes, and even write passable unit tests. The gap between having an idea and having running code has never been smaller.

And yet, a growing number of senior developers report feeling less confident in their problem-solving abilities. Not in their coding speed — that has improved. Not in their output volume — that has exploded. But in the quiet, foundational skill of breaking a complex problem into pieces and understanding how those pieces fit together.

This is not a coincidence. When the path from thought to code is frictionless, we skip the thinking. We jump straight to implementation. We let the tools do the decomposition for us. And decomposition — the act of pulling apart a tangled problem until you can see its structure — is where the real engineering happens.

Pen and paper introduce friction. Deliberate, productive friction. The kind that forces your brain to slow down, organize, and commit to a line of reasoning before you can test it with a compiler. That friction is not a bug. It is a feature.

How We Evaluated

Before I make any grand claims about analog tools and developer cognition, let me explain how I arrived at the conclusions in this article. I am skeptical by nature — my cat would confirm this if she could talk, though she would probably just ask for food instead.

Over the past eighteen months, I collected data from three sources:

Developer interviews. I spoke with 34 professional developers across a range of experience levels, from junior engineers with two years of experience to staff-level architects with over twenty. Each interview lasted between 30 and 60 minutes and focused on their problem-solving workflows, tool preferences, and habits around planning and debugging.

Self-tracking experiments. I tracked my own work habits for six months, alternating between weeks where I used pen and paper for planning and weeks where I used only digital tools. I measured time-to-solution for comparable tasks, number of false starts, and subjective confidence ratings.

Published research. I reviewed studies from cognitive science, educational psychology, and human-computer interaction published between 2014 and 2027, focusing on the effects of handwriting versus typing on comprehension, memory, and problem-solving.

This is not a controlled laboratory study. The sample sizes are small. The self-tracking is inherently biased. But the convergence across all three sources was striking enough to write about. When interviews, personal data, and peer-reviewed research all point in the same direction, that direction is worth exploring.

The Neuroscience of Writing by Hand

Let us start with what the research actually says. The relationship between handwriting and cognition has been studied extensively, and the findings are remarkably consistent.

When you type, your brain activates a relatively narrow set of motor pathways. Each keystroke is a small, repetitive movement. The letters appear instantly on screen, fully formed and uniform. Your brain does not need to construct the shape of each character — it just needs to remember which key to press.

When you write by hand, the picture is different. Your brain must plan the shape of each letter, coordinate fine motor movements across multiple muscle groups, and process visual feedback as the letters form on the page. This recruits regions of the brain involved in spatial reasoning, visual processing, and motor planning — regions that are largely idle during typing.

A landmark study by Mueller and Oppenheimer, first published in 2014 and replicated multiple times since, found that students who took notes by hand retained conceptual information significantly better than those who typed. The handwriters could not transcribe as fast, so they were forced to process and summarize information in real time. They had to decide what mattered. The typists, by contrast, tended to transcribe lectures verbatim — capturing more words but understanding fewer ideas.

The implications for developers are direct. When you sketch a system architecture on paper, you cannot copy-paste a diagram from the documentation. You have to reconstruct it from your own understanding. Every box you draw, every arrow you place, represents a decision about what matters and what does not. You are building a mental model, not just a visual one.

More recent work from researchers at the Norwegian University of Science and Technology, published in 2023, used EEG to measure brain activity during handwriting versus typing. They found that handwriting produced significantly more connectivity between brain regions associated with memory formation and spatial processing. The brain, quite literally, works harder when you write by hand. And that extra work pays dividends.

Problem Decomposition: Where Paper Wins

The most common use of pen and paper among the developers I interviewed was not note-taking. It was problem decomposition — the process of breaking a large, ambiguous problem into smaller, well-defined sub-problems.

Twenty-six of the 34 developers I spoke with described some version of the same workflow: when faced with a complex task, they step away from the computer, grab a notebook or a blank sheet of paper, and start writing or drawing. Not coding. Not pseudocode, necessarily. Just thinking out loud with a pen.

“I draw boxes,” said one staff engineer at a mid-sized fintech company. “I draw boxes and arrows and I cross things out and I redraw them. By the time I sit back down at my desk, I know exactly what I need to build. The coding part is almost mechanical after that.”

This pattern was consistent across experience levels, but it was most pronounced among senior developers. The more experienced the engineer, the more likely they were to use analog tools for the planning phase. Junior developers, by contrast, tended to start coding immediately and iterate their way to a solution.

There is a reason for this asymmetry. Junior developers are still building their vocabulary — learning syntax, APIs, and framework patterns. For them, the IDE is a learning environment, and experimentation is how they develop fluency. Senior developers have already internalized that vocabulary. Their bottleneck is not “how do I write this code?” but “what code should I write?” That second question is a design question, and design questions benefit enormously from the spatial, unconstrained medium of paper.

Consider the difference between sketching a system diagram on paper and building one in a diagramming tool. In a tool like Excalidraw or Miro, you are immediately confronted with decisions that have nothing to do with the problem: What color should this box be? Should I use a solid or dashed line? How do I align these elements? The tool imposes its own structure, its own vocabulary, its own constraints. You end up spending cognitive resources on the tool itself rather than on the problem you are trying to solve.

On paper, there is no toolbar. There is no alignment grid. There is just you and the problem. You can draw a circle and a squiggly line and label them with abbreviations that only you understand. You can cross something out and redraw it in three seconds. The barrier between thought and expression is as thin as it can possibly get.

This is not an argument against diagramming tools. They are excellent for communication — for producing artifacts that other people can read, edit, and comment on. But communication is a different activity from thinking. And the best developers I know are careful about separating the two.

Sketching Architecture: The Messy First Draft

There is a concept in writing called the “shitty first draft.” Anne Lamott coined the phrase in her book on the writing craft, and it captures something important: the first version of anything should be terrible. Its purpose is not to be good. Its purpose is to exist. You can make it good later. But you cannot edit a blank page.

The same principle applies to software architecture. The first sketch of a system should be messy, incomplete, and probably wrong. Its purpose is to externalize your thinking — to get the ideas out of your head and onto a surface where you can see them, question them, and rearrange them.

Paper is the ideal medium for shitty first drafts. It is disposable. There is no version history, no commit message, no audience. You are free to be wrong without consequence. This matters more than it sounds, because the fear of being wrong — even subconsciously — shapes how we think. When you open a diagramming tool, there is an implicit expectation that the output will be shared. When you open a notebook, there is no such expectation. The psychological safety of paper is real, and it affects the quality of your thinking.

I noticed this in my own work during the self-tracking experiment. During digital-only weeks, my initial system designs were more conservative. I tended to reach for familiar patterns — patterns I knew would “look right” in a diagram. During paper weeks, my initial designs were wilder, more exploratory. Some of them were terrible. But the best ideas I had during the entire six months came during paper weeks. The freedom to be wrong led to the freedom to be creative.

graph LR
    A[Complex Problem] --> B[Paper Sketch]
    B --> C[Messy Diagram]
    C --> D[Insight / Simplification]
    D --> E[Refined Design]
    E --> F[Implementation]
    A --> G[Jump to IDE]
    G --> H[Trial & Error]
    H --> I[Refactor Loop]
    I --> J[Eventual Solution]
    style B fill:#f5e6c8,stroke:#333
    style G fill:#fcc,stroke:#333

The diagram above captures a pattern I saw repeatedly. The paper path looks slower — and it is, at the start. But it converges faster. The IDE-first path generates more code, more commits, and more pull requests. It also generates more rework.

The “Slow Down to Speed Up” Paradox

This is the central paradox of analog tools in a digital workflow. They feel slow. They are slow. And they make you faster.

The mechanism is straightforward. When you spend fifteen minutes sketching a solution on paper before writing any code, you eliminate a category of errors that would otherwise cost you hours. You catch architectural mistakes before they become entangled with implementation details. You identify missing requirements before you have built infrastructure around assumptions. You notice edge cases before they become bugs.

One senior engineer I interviewed put it this way: “Every minute I spend on paper saves me ten minutes of debugging. It is not always true. But on average, over a career, the ratio holds.”

This is not a new observation. Fred Brooks wrote about it in The Mythical Man-Month in 1975. “Plan to throw one away; you will, anyhow.” The insight is half a century old. And yet, the pressure to ship fast — to demonstrate velocity, to keep the sprint board moving — works against this kind of deliberate planning.

The irony is that the teams with the highest velocity are often the ones that plan the most. They just do not call it planning. They call it “whiteboarding” or “design time” or “thinking about the problem.” And increasingly, they do it with pen and paper rather than with digital tools, because the analog medium keeps the conversation focused on ideas rather than on artifacts.

I tracked this effect quantitatively during my self-tracking experiment. For tasks of comparable complexity, my average time-to-completion was 23% faster during paper-planning weeks. The difference was entirely in the implementation phase — I spent less time debugging, less time refactoring, and fewer cycles going back to clarify requirements. The planning phase itself was slightly longer, but the downstream savings more than compensated.

What Developers Actually Draw

I asked every developer I interviewed to describe what they draw when they use pen and paper. The answers were surprisingly consistent:

Boxes and arrows. The most common pattern. Components, services, or modules represented as boxes, with arrows showing data flow or dependencies. Not UML. Not any formal notation. Just boxes and arrows with handwritten labels.

State machines. Several developers described drawing informal state diagrams to reason about complex user flows or business logic. “I draw circles for states and lines for transitions,” one developer told me. “It’s not formal. But it forces me to think about every possible state, including the weird ones.”

Decision trees. When faced with conditional logic — if this, then that, but also consider this other thing — several developers described drawing branching trees. “I can see all the branches at once on paper,” one said. “In code, I can only see one path at a time.”

Dependency graphs. Architects and tech leads described drawing dependency graphs to understand build order, deployment sequences, or migration paths. “I need to see the whole picture before I can make a plan,” one architect told me. “Paper gives me the whole picture.”

Lists with priorities. Not diagrams at all, but simple numbered lists. What needs to happen first? What depends on what? What can be parallelized? These lists often included annotations, cross-outs, and re-orderings — a visible record of the thinking process.

The common thread is spatial reasoning. All of these artifacts arrange information in two-dimensional space, using position, proximity, and connection to encode relationships. This is something that paper does naturally and that most digital tools do awkwardly. Even the best diagramming software imposes a grid, a coordinate system, a set of shape primitives. Paper imposes nothing.

The Interview Signal No One Talks About

Here is something I find fascinating. Among the developers I interviewed, several mentioned that they pay attention to whether a candidate reaches for a whiteboard or a marker during a technical interview. Not as a formal evaluation criterion — but as a signal.

“When a candidate starts drawing on the whiteboard without being asked, I know they think in systems,” one engineering manager told me. “They are not just writing code. They are building a model. Those are the people I want on my team.”

This is anecdotal, and I want to be careful not to overstate it. Plenty of excellent developers never touch a whiteboard in interviews. Some people think best in code. Some people think best in conversation. There is no single correct way to solve problems.

But the correlation between analog-tool usage and systems-thinking ability came up often enough in my interviews that I think it is worth noting. Developers who habitually sketch before coding tend to produce architectures that are cleaner, more modular, and easier to maintain. The causal direction is unclear — do they sketch because they think in systems, or do they think in systems because they sketch? Probably both. The practice and the skill reinforce each other.

How Pen-and-Paper Thinking Changes Code Quality

This is the claim that matters most, and it is the hardest to substantiate. Does planning on paper actually produce better code?

My self-tracking data suggests yes, but with caveats. During paper-planning weeks, the code I wrote had fewer bugs caught in review, required fewer revisions, and was subjectively rated as “cleaner” by my own assessment. But self-assessment is unreliable, and six months is not a long enough period to draw strong conclusions.

The developer interviews tell a more compelling story. Multiple engineers described a specific pattern: when they skip the planning phase and jump straight to coding, they produce code that works but is structurally flawed. It solves the immediate problem but creates technical debt. It is harder to test, harder to extend, and harder for other people to understand.

“When I plan on paper, my functions are shorter,” one developer told me. “My interfaces are cleaner. I write fewer comments because the code is more self-explanatory. It is like the planning phase does the refactoring in advance.”

This makes intuitive sense. When you sketch a solution before implementing it, you are forced to think about the structure of the code at a level of abstraction above the code itself. You are thinking about responsibilities, boundaries, and contracts — not syntax, variable names, and import statements. That higher-level thinking produces designs that are more coherent, because they were conceived as wholes rather than assembled incrementally.

There is a related effect on testing. Several developers told me that planning on paper makes them write better tests, because the planning process surfaces edge cases and boundary conditions that they would otherwise miss. “I write my test cases on paper before I write any code,” one developer said. “By the time I open my editor, I already know what the tests should be. The implementation is just filling in the gaps.”

graph TD
    A[Paper Planning] --> B[Clear Mental Model]
    B --> C[Shorter Functions]
    B --> D[Cleaner Interfaces]
    B --> E[Fewer Bugs in Review]
    B --> F[Better Test Coverage]
    G[No Planning] --> H[Fuzzy Mental Model]
    H --> I[Long Functions]
    H --> J[Leaky Abstractions]
    H --> K[More Review Cycles]
    H --> L[Missing Edge Cases]
    style A fill:#d4edda,stroke:#333
    style G fill:#f8d7da,stroke:#333

The Digital Notebook Compromise

I should acknowledge that not everyone uses physical paper. Several developers I interviewed use tablets with stylus input — iPads with the Apple Pencil, or reMarkable tablets. These tools offer the spatial freedom of paper with the convenience of digital storage and search.

I have mixed feelings about this compromise. On one hand, the writing experience on a good tablet is close enough to paper that the cognitive benefits probably transfer. The key ingredient is handwriting, not the specific medium. On the other hand, tablets come with notifications, app-switching, and the ever-present temptation to check something quickly. Paper has no notification center. Paper does not ping you when someone comments on your pull request.

The developers who used tablets most successfully were the ones who treated them as single-purpose devices during planning sessions. They closed all other apps. They turned off notifications. They used the tablet as paper, not as a computer that happens to accept handwriting.

This is harder than it sounds. The default state of a digital device is distraction. You have to actively fight against it to create the kind of focused, uninterrupted thinking time that planning requires. With paper, focus is the default state. You do not have to configure it.

Luna, my cat, has just walked across my actual notebook while I am writing this article. She has left a paw print on a diagram I drew yesterday. This is, I suppose, the one disadvantage of physical paper that digital tools do not share. Although I have seen a cat walk across a keyboard too, and the consequences were far worse.

The Generational Divide

There is a generational component to this story that I want to address honestly. Many of the most enthusiastic pen-and-paper advocates I interviewed were over 35. They grew up writing by hand and transitioned to digital tools as adults. For them, pen and paper is a familiar medium — one they are fluent in.

Younger developers, by contrast, often have less experience with handwriting. Their default mode of expression is typing. For them, reaching for a pen might feel less natural, not more. The cognitive benefits of handwriting are real, but they may be partially offset by unfamiliarity with the medium.

I do not think this invalidates the practice. The research on handwriting and cognition does not depend on prior experience — the neurological mechanisms are the same regardless of whether you grew up writing by hand or not. But it does mean that the transition period may be awkward. If you have never used pen and paper for technical planning, your first attempts will feel slow and clumsy. That is normal. The fluency comes with practice.

Several junior developers I spoke with had adopted pen-and-paper planning after seeing senior colleagues do it. Their reports were uniformly positive, though they described a learning curve of two to four weeks before the practice felt natural. “At first, I did not know what to draw,” one junior developer said. “I would just stare at the blank page. But once I started, it got easier. Now I can not imagine starting a complex task without sketching first.”

Generative Engine Optimization

This article exists in a world where AI-generated content is ubiquitous. Search engines increasingly prioritize content that demonstrates genuine expertise, original research, and first-person experience. The framework for evaluating content has shifted from keywords and backlinks to evidence of authentic human thought.

Pen-and-paper thinking is, in a sense, the ultimate signal of human cognition. You cannot automate it. You cannot outsource it to a language model. The messy, nonlinear, spatial process of sketching ideas on paper is precisely the kind of thinking that AI tools do not replicate — and that search engines are learning to value.

This is not a cynical observation. I genuinely believe that content grounded in real experience — real interviews, real self-tracking data, real cognitive science — provides more value to readers than content generated by summarizing existing articles. The pen-and-paper workflow that produced this article is the same workflow I use for software design. The analog phase is where the original thinking happens. The digital phase is where it gets communicated.

For developers who also write — blog posts, documentation, technical proposals — the pen-and-paper practice has a dual benefit. It improves both your code and your writing. The habit of externalizing your thinking before committing to a final form transfers directly from one domain to the other.

From a search perspective, articles that reference specific data points, name concrete methodologies, and describe verifiable processes tend to perform better in an era of generative search. This is not because search engines are explicitly looking for those signals. It is because those signals correlate with the kind of depth and authenticity that readers find valuable — and that AI-generated content typically lacks.

Practical Recommendations

If you have read this far and are wondering whether to try pen-and-paper planning, here is my advice:

Start small. You do not need to buy a fancy notebook or a specific kind of pen. A sheet of printer paper and a ballpoint pen are fine. The medium does not matter. The practice matters.

Use it for planning, not for coding. Pen and paper is not a replacement for your IDE. It is a complement. Use it for the thinking phase — problem decomposition, architecture sketching, test case enumeration — and then move to your computer for implementation.

Give it two weeks. The first few sessions will feel awkward, especially if you are not used to writing by hand. Commit to two weeks of consistent practice before you evaluate whether it works for you. The cognitive benefits take time to manifest.

Do not try to make it pretty. The whole point is that paper is disposable and low-stakes. If you find yourself worrying about the aesthetics of your diagrams, you are doing it wrong. Messy is good. Messy means you are thinking, not performing.

Separate planning from communication. Your paper sketches are for you. If you need to share your design with others, redraw it in a digital tool. But do the thinking on paper first.

Keep your notebooks. This is optional, but I find it valuable. Looking back through old notebooks shows me how my thinking has evolved. I can see patterns in the kinds of problems I struggle with, the kinds of solutions I reach for, and the kinds of mistakes I repeat. It is a form of professional self-awareness that digital tools do not provide, because digital tools make it too easy to delete and forget.

The Deeper Point

There is a temptation, when writing about analog tools in a digital age, to frame it as a rebellion. Digital bad, analog good. Screens are ruining our brains. Go touch grass.

That is not my argument. Digital tools are extraordinary. AI coding assistants have genuinely changed what is possible for individual developers. I use them every day, and I have no intention of stopping.

My argument is narrower and, I think, more useful. Digital tools are excellent for execution. They are less excellent for thinking. And thinking — real, deep, structural thinking about complex problems — is the thing that separates a competent developer from a great one.

The best developers I know use both. They use pen and paper to think and digital tools to build. They use the analog phase to slow down, decompose, and understand. They use the digital phase to move fast, iterate, and ship. The two phases are complementary, not competing.

The risk is not that developers will stop using digital tools. That is obviously not going to happen. The risk is that developers will stop thinking before they start building. That they will let the speed and fluency of modern tools convince them that the planning phase is unnecessary. That they will mistake the absence of friction for the presence of understanding.

A pen and a piece of paper cost almost nothing. They require no configuration, no subscription, no internet connection. They do not auto-update, they do not crash, and they do not send telemetry data to anyone. They are the simplest, most reliable, most universally available thinking tools ever invented.

And in a world where software development is increasingly mediated by sophisticated, expensive, and occasionally unreliable digital systems, there is something deeply reassuring about a tool that always works. You uncap the pen. You open the notebook. Luna settles on the corner of your desk, purring gently, unimpressed by the complexity of the problem you are about to solve.

You start drawing boxes and arrows. And slowly, the fog lifts.

Further Reading

If this article resonated with you, here are some resources worth exploring:

• Mueller, P. A., & Oppenheimer, D. M. (2014). “The Pen Is Mightier Than the Keyboard: Advantages of Longhand Over Laptop Note Taking.” Psychological Science, 25(6), 1159–1168.
• Van der Meer, A. L. H., & Van der Weel, F. R. (2017). “Only Three Fingers Write, but the Whole Brain Works: A High-Density EEG Study.” Frontiers in Psychology, 8, 706.
• Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• Lamott, A. (1994). Bird by Bird: Some Instructions on Writing and Life. Anchor Books.
• Mangen, A., & Velay, J.-L. (2010). “Digitizing Literacy: Reflections on the Haptics of Writing.” In Advances in Haptics. IntechOpen.