Dictating Code Comments: A Developer's Honest Take

Nobody writes enough documentation. Every developer knows this. The code makes sense right now, in their head, with the full context of why they made that decision at 4pm on a Tuesday. Six months later, it is archaeology.

The reason documentation gets skipped is not laziness. It is friction. Switching from thinking-in-code to writing-in-prose breaks flow. Dictation reduces that friction enough to actually make a difference.

What Developers Actually Use Voice For

Code syntax is not where dictation shines. Punctuation-heavy, symbol-dense syntax is slower to dictate than to type, and error-prone. Nobody wants to say "open paren, close paren, arrow, open curly" for a callback.

But documentation, comments, commit messages, and technical notes are almost pure prose. That is where voice input pulls ahead. These are the exact tasks that developers skip when the writing friction is high, and they are the ones that matter most for long-term maintainability.

A commit message like "fixed the thing" exists because writing a real one felt like too much work. Dictating a real commit message takes about eight seconds.

A Practical Workflow

The pattern that works best is voice for prose, keyboard for code. Keep both in your workflow and use each where it fits.

When you finish a function, press the dictation key, explain what it does in one or two sentences, and move on. The comment gets written before you forget your own reasoning. With something like VoiceInk, this is a single keystroke: hold, speak, release. The text lands wherever your cursor is sitting, including directly in your editor.

For longer documentation blocks, step away from the code and just talk it out. Describe the module, the design decisions, the edge cases you handled and the ones you didn't. You will write more than you would typing, and you will write it faster.

Where It Gets Uncomfortable

Technical terminology can trip up any transcription tool. Variable names, library names, domain-specific jargon: these require a short adjustment period. Most tools improve with repeated use, and you develop habits around how you phrase things.

Open offices are a problem. Dictating in a shared space is not always practical, and it is not always welcome. If you have a private office or work remotely, this is not an issue. If you are in a noisy bullpen, you will need headphones and a good close-mic setup, or you will need to save dictation for async work.

The RSI Angle

Developers are not immune to repetitive strain. Long hours on a keyboard, especially combined with mouse use, add up. Wrists, forearms, and shoulders take the load.

Shifting even 20 percent of daily text output to voice reduces that load meaningfully. Documentation, Slack messages, PR descriptions, ticket comments: these are all text that does not need to be typed. Dictating them gives your hands a break during the parts of the workday that do not require the keyboard.

This is not a cure for RSI, but it is a real reduction in the volume of keystrokes your hands have to handle each day.

Starting Small

You do not have to rebuild your entire workflow. Start with commit messages for one week. Every commit, speak the message instead of typing it. Notice whether they get longer and more descriptive when the writing friction drops.

Then try inline comments. Then try writing one documentation block per day by voice.

Most developers who stick with it for two weeks find that the awkwardness fades and the speed advantage becomes obvious for anything that is not syntax.

Your future teammates, and your future self, will read that documentation. The bar for actually writing it is lower than you think if you are willing to say it out loud instead of type it.