9 min read

How to Take Notes While Coding (Without Breaking Flow)

Every developer loses ideas while coding. The fix isn't a better note app. It's a faster capture method. Here are the approaches that actually work, ranked by how much they interrupt your focus.

M
Massi · 0xmassi.dev
developer note takingnote taking for programmerscoding workflowproductivitymacOSquick capturefocusflow statelocal-first

The thought you lost five minutes ago

You're three functions deep in a refactor. You finally see how the pieces connect. Then a thought appears: "this endpoint needs rate limiting before we ship." It's important. You know it's important. But you're mid-thought on something else entirely.

So you do one of two things. You either stop what you're doing, open a note app, wait for it to load, find somewhere to put the thought, type it out, and then spend the next two minutes trying to remember where you were in the refactor. Or you tell yourself you'll remember it later. You won't.

This happens to every developer, multiple times a day. It's not a memory problem. It's a capture problem.

Research on context switching in software development shows that interruptions cost an average of 23 minutes to recover from. And the cruelest part is that the interruption doesn't have to come from someone else. Opening a note app in the middle of deep work is a self-inflicted interruption.

Why most note apps fail developers

The note apps that developers typically reach for weren't designed for this problem.

Notion wants you to organize. You open it and you're already thinking about which workspace, which page, which database. By the time you've navigated to the right place, the thought is half gone and your mental model of the code is completely unloaded.

Obsidian is powerful, but power comes with surface area. Daily notes, templates, backlinks, graph views. It's a knowledge management system, not a capture tool. Great for writing documentation later. Terrible for "quick, write this down before I forget."

Apple Notes is simpler, but it still takes 3 to 5 seconds to open, find a note, and start typing. That doesn't sound like much. But when you're holding a complex mental model in working memory, those seconds are enough to lose a thread you can't get back.

Even physical sticky notes on your monitor are better than most of these, because you don't have to navigate anything. You just write. The problem with physical notes is that you can't search them later, and they get lost.

Five approaches that actually work

I've tried everything. Comments in code, Slack messages to myself, voice memos, plain text files, dedicated apps. Here's what I've landed on, ranked by how much they interrupt your flow.

1. Inline comments (zero context switch)

The fastest capture method is one that doesn't leave your editor at all.

// TODO: add rate limiting before launch
// FIXME: this breaks if the user has no email
// NOTE: revisit after the auth migration

You're already in the file. You're already typing. Adding a comment takes two seconds and zero context switching. Your hands never leave the keyboard, your eyes never leave the code.

The downside is that these comments live in the code. They move with the file, get buried in diffs, and are easy to forget. If you use TODO comments, install a TODO Highlight extension and periodically grep for them. Otherwise they become noise that everyone ignores.

Best for: thoughts directly related to the code you're editing right now.

2. Scratch buffer in your editor (minimal switch)

Most editors have a way to keep a scratch file open. In VS Code, you can open a new untitled file (Cmd+N) and keep it in a split pane. In Vim, a :new buffer. In JetBrains, a scratch file (Cmd+Shift+N).

The scratch buffer stays open next to your code. When a thought hits, you switch panes, type it, switch back. Maybe five seconds of interruption. The thought is captured and you didn't leave your development environment.

The downside is that scratch buffers are ephemeral. Close the editor and they're gone (unless you explicitly save them somewhere). They also become messy fast if you use one buffer for everything.

Best for: thoughts you need to act on within the current coding session.

3. Keyboard-shortcut capture (sub-second switch)

This is the approach I use most. A global keyboard shortcut that opens a tiny input field over whatever you're doing. You type the thought, hit Enter, and you're back in your editor. The whole thing takes under two seconds.

Several apps do this:

  • Stik (free, open source) — Cmd+Shift+Space opens a floating capture window. Note saves as a local markdown file. No account, no cloud, no navigation.
  • Drafts — launches to a blank page on a keyboard shortcut. Great on iOS, available on Mac.
  • Tot — menu bar app with 7 text scratchpads. Simple, but no search.

The key insight is that the capture window should open empty and ready to type. No choosing a notebook, no picking a folder, no loading a database. You press a shortcut, you type, you close. That's it.

Best for: any thought that isn't directly about the code on screen (reminders, questions, ideas, tasks).

4. Terminal-based capture (for terminal-native devs)

If you live in the terminal, the fastest capture might be a one-liner:

echo "rate limit the /api/upload endpoint" >> ~/notes.md

Or wrap it in an alias:

alias note='echo "$(date +%H:%M) $@" >> ~/notes.md'
# usage: note remember to update the API docs

No app to open, no GUI to navigate. Just type and go. You can get fancier with tools like nb or jrnl, but a simple append-to-file alias covers 90% of what you need.

The downside is that plain text files become hard to search as they grow. And if you forget to review them, the notes pile up and become useless.

Best for: developers who rarely leave the terminal and want the absolute minimum friction.

5. Voice notes (true zero-interruption)

When your hands are on the keyboard and you don't want to stop typing, voice is the only way to capture without any physical interruption.

On macOS, pressing Fn Fn (double-tap the function key) activates dictation. Say your thought, hit Fn again, and the transcription appears wherever your cursor is. You can do this into a scratch buffer, a text file, or a capture app.

You can also use the Voice Memos app or a service like Otter.ai for longer recordings, but for quick capture during coding, built-in dictation is enough.

The downside is that you're talking out loud, which doesn't work in an open office. And transcription quality varies with accents and technical jargon ("refactor the singleton" might become "refactor the single ton").

Best for: remote workers or solo developers who want hands-free capture.

The real pattern behind all of these

Every good developer note taking method has the same three properties:

  1. Sub-three-second capture. If it takes longer than that, your working memory starts dropping context. The method has to be fast enough that you don't lose your train of thought.

  2. No navigation. The moment you have to choose where to put the note, you're thinking about organization instead of coding. Good capture is always "write it and forget it." Organize later.

  3. Searchable later. The note is useless if you can't find it tomorrow. Even a plain text file with dates is better than a thought you "remember" (and don't).

The biggest mistake developers make with note taking is conflating capture with organization. They try to file the note in the right place the moment they write it. That's two tasks disguised as one, and it doubles the interruption.

Capture fast. Organize later. Review weekly. That's the whole system.

What I actually do

My setup is boring and that's the point:

  1. During coding: Cmd+Shift+Space opens Stik's capture window. I type the thought, hit Enter, and I'm back in VS Code in under two seconds. The note saves as a markdown file in ~/Documents/Stik/.

  2. Code-specific thoughts: // TODO: comments inline. I grep for them before each PR.

  3. End of day: I open Stik's note list and scan what I captured. Most notes turn into tasks (moved to Linear), some become documentation updates, some I just delete.

  4. Finding old notes: Stik's on-device semantic search means I don't have to remember the exact words I used. I search by meaning, not by keyword.

This isn't a complex system. There's no graph database, no daily note template, no Zettelkasten ritual. It's just a fast input and a smart search. That's all most developers need.

The cost of not capturing

Let's do some rough math. Say you lose 3 ideas per day because you didn't write them down. Some are tasks you forget until they bite you. Some are improvements you never make. Some are bugs you notice but don't track.

Over a year, that's roughly 750 lost thoughts. Not all of them are important. But some of them are. The rate limiting you forgot about until it caused an incident. The refactor idea that would have saved a week of tech debt. The edge case you noticed but didn't file.

The cost of a good note taking system for programmers is two seconds per thought. The cost of not having one is invisible until it isn't.

Try it

If you're currently losing thoughts while coding, pick the method that matches how you work:

  • You never leave the editor → inline comments + scratch buffer
  • You want fast capture without setupStik (free, open source, Cmd+Shift+Space)
  • You live in the terminalecho alias to a text file
  • You don't want to stop typing → voice dictation (Fn Fn on Mac)

Start with one. Use it for a week. See how many thoughts you actually capture that you would have otherwise lost.


Frequently asked questions

How do you take notes while coding without losing focus?

The key is keeping capture under three seconds. Use a global keyboard shortcut (like Cmd+Shift+Space) that opens a blank input over your editor. Type the thought, hit Enter, and you're back in your code. No app switching, no navigation, no choosing a folder. The note gets saved automatically and you organize it later.

What's the best note taking app for developers?

It depends on your workflow. For quick capture during coding, lightweight tools like Stik, Drafts, or a simple text file work best. For long-form knowledge management, Obsidian or Notion are more suitable. The best app is the one fast enough that you actually use it in the moment.

Should I use TODO comments or a separate note app?

Both. TODO comments are perfect for thoughts directly tied to the code you're editing, because they live right where the context is. But for ideas, reminders, and tasks unrelated to the current file, a separate capture method is better. You don't want unrelated thoughts cluttering your codebase.

How do I organize developer notes?

Don't organize at capture time. Write the note as fast as possible and move on. Set aside five minutes at the end of the day to review what you captured: move tasks to your project tracker, turn good ideas into tickets, delete the rest. If your notes are searchable (using semantic search or consistent keywords), you don't need a complex folder structure.

Is note taking during coding actually productive?

Research on interruption recovery in software engineering shows that context switches cost an average of 23 minutes to recover from. A two-second note capture is not a context switch. Losing a thought and spending 20 minutes rediscovering it later is. Fast note capture is one of the highest-leverage productivity habits a programmer can build.

What do developers use to take notes?

Common tools include inline code comments, scratch buffers in the editor, dedicated capture apps like Stik or Drafts, terminal-based tools like nb or plain text files, and knowledge management systems like Obsidian. The most effective developers tend to separate quick capture (fast, simple tools) from long-term knowledge management (more structured tools).