How to Dictate Code Comments Without Losing Your Mind

Nobody loves writing documentation. The code is done, the problem is solved, and now you have to explain it to a future version of yourself who will have forgotten everything. It's the part most developers skip or rush. Dictation doesn't make it fun, but it makes it fast enough that skipping it stops feeling justified.

Why Docs and Comments Are Ideal for Voice

Code itself is a bad fit for voice dictation. Symbol names, brackets, operators, indentation logic: all of that is painful to speak and error-prone to capture. Don't try to dictate code.

But the prose around code is a different story. Inline comments, function docstrings, README sections, architecture decision records, Confluence pages, Notion docs: all of these are just writing. Natural language, full sentences, explanatory prose. Voice handles all of it well.

If you spend 30 minutes a day on documentation tasks, dictating them instead of typing could cut that to 15. Over a year, that's roughly 90 hours returned to you.

Setting Up the Workflow

The simplest setup: keep your editor open, cursor positioned in the comment or doc block, and use a dictation tool that activates with a hotkey and outputs directly to wherever your cursor is.

VoiceInk works well for this because it's always-available on Mac. Press the hotkey, speak, release. The text appears in your editor without switching windows or copying from another app. It processes locally, so it works without an internet connection, which matters if you're working on an air-gapped machine or a slow connection.

You don't need to configure anything per-application. It works in VS Code, Xcode, JetBrains IDEs, terminal-based editors, and anywhere else you'd normally type.

A Practical Example

You've just written a function that handles retry logic with exponential backoff. You need a docstring. Instead of typing it:

Position the cursor in the docstring block. Press the hotkey. Say: "Retries the given operation up to max underscore attempts times, using exponential backoff between each attempt. The delay starts at base underscore delay seconds and doubles on each retry. Raises the last exception if all attempts fail."

Release the hotkey. Clean up any minor transcription errors. Done. That took about twelve seconds of speaking and thirty seconds of light editing. The typed version would have taken two to three minutes.

Handling Technical Terms

The main friction in dictating for code is vocabulary. Dictation engines sometimes mishear technical terms, library names, or acronyms. A few strategies help:

Speak proper nouns slowly and clearly. "React" and "Redux" both transcribe well. "Pytest" sometimes comes out as "pie test" and needs a quick correction. Build a habit of scanning the first line of every dictated block before moving on.

For terms you use constantly, check whether your dictation tool supports custom vocabulary or text expansion. Even a simple text expander that converts "rek" to "React" saves repeated corrections.

Don't try to dictate variable names inline. Say "the retry count variable" in prose and then type the actual variable name. Mixing dictated prose with typed identifiers is faster than fighting the transcription engine on camelCase names.

Other High-Value Targets for Developer Dictation

Beyond inline comments and docstrings, consider dictating:

• Pull request descriptions. The "what changed and why" section is pure prose and often written hurriedly. Speaking it out loud tends to produce more complete explanations.
• Ticket comments and status updates in Jira, Linear, or GitHub Issues.
• Slack messages explaining technical decisions to non-technical colleagues. These benefit from a conversational tone anyway.
• Personal notes and meeting follow-ups captured in Obsidian, Notion, or a plain text file.

None of these require code. All of them benefit from being faster to produce.

The Bigger Picture

Developers who dictate aren't replacing their keyboards. They're using voice for the parts of the job that are just writing, and keeping their hands for the parts that actually require them.

If documentation is the thing you always mean to do better, voice is a practical place to start.