Dictating Documentation: A Developer's Honest Take

Documentation is the task every developer knows matters and almost nobody wants to do. It sits at the bottom of the sprint, gets cut when time runs short, and accrues into a debt that future-you pays with interest. The problem is rarely that developers do not understand the code well enough to explain it. The problem is that writing feels slow compared to everything else in the workflow.

Dictation does not fix bad documentation culture. But it removes one of the most legitimate excuses for skipping it.

The Actual Time Cost of a Docstring

A good docstring for a non-trivial function takes maybe three minutes to type well. That includes the time to open the comment block, choose your words carefully, proofread, and close it. Three minutes does not sound like much until you realize you have thirty functions in the file and you have been awake since 7am.

The same docstring, dictated, takes about forty seconds. You already know what the function does. You just explained it in the PR description. Speaking that explanation directly into the comment block is faster than any other method.

Where Dictation Fits in a Dev Workflow

Code itself is not a great dictation target. Variable names, syntax, and special characters are awkward to speak. Nobody wants to dictate for i in range(len(arr)). That is still a typing job.

But a large portion of what developers write is not code. It is:

• Inline comments explaining why a decision was made
• README sections describing setup steps
• Confluence or Notion pages documenting architecture
• Slack messages explaining a bug to a colleague
• Ticket descriptions and acceptance criteria
• Commit messages that are actually informative

All of that is prose. All of it is faster dictated than typed.

The "Explain It Out Loud" Method

The best documentation technique for developers who hate writing documentation is also the simplest. After you finish a function or a module, before you switch context, turn on VoiceInk and explain what you just built as if you are talking to a new team member.

Do not try to write documentation. Just explain the thing. "This function takes an array of user objects and returns only the ones with verified emails. It uses filter instead of a loop because we needed it to compose with the rest of the pipeline. Edge case: if the array is empty it returns an empty array, not null."

That took maybe twenty seconds to say. It is also a better comment than most codebases have.

Hands-Off Capture During Debugging

One underrated use case is note-taking while debugging. When you are deep in a problem, switching to a text editor to write down what you tried breaks your concentration. Speaking a quick note, "tried memoizing the selector, no change, the re-render is happening upstream," keeps your hands on the keyboard and your head in the problem.

VoiceInk drops text into whatever app is active, so you can keep a running debug log in a scratch note by just speaking between attempts. No switching windows, no interrupting flow.

Getting Set Up

You do not need specialized hardware. The built-in microphone on a recent MacBook is good enough for dictation in a quiet office. A USB condenser mic or a quality headset improves accuracy, especially in noisier environments. The Blue Yeti and the Rode NT-USB Mini are both solid choices under $150 if you want to go further.

VoiceInk runs locally on your Mac, so nothing you dictate leaves your machine. For developers working on proprietary systems or under NDAs, that matters. Cloud-based dictation tools send your audio to external servers. Local transcription keeps your architecture decisions and internal documentation where they belong.

The Excuse Is Gone

Developer documentation is bad because it is slow to write, not because developers cannot write. Remove the slowness and you remove most of the resistance.

You do not have to adopt a full voice-first workflow. Just try dictating the next ten docstrings you would have skipped. See what the time actually feels like.