Dictating Code Comments: A Developer's Honest Take

Documentation is the task developers universally agree is important and universally find reasons to skip. The code is working, the deadline is close, and writing a paragraph explaining what a function does feels like unnecessary overhead. The result is a codebase that future-you will hate.

Dictation does not solve the motivation problem, but it removes the friction enough that the behavior changes.

Where Developers Lose the Most Time to Writing

It is not the code itself. Most developers type code quickly. The slow parts are the prose parts. Inline comments that explain non-obvious logic. Function docstrings. README sections. Architecture decision records. Ticket descriptions. Pull request summaries.

All of these are natural language writing tasks, and they carry the same typing overhead as any other writing. A thorough PR description that might take 10 minutes to type can be spoken in 2 minutes. If you write 5 PRs a week, that is 40 minutes back without changing anything about how you code.

What Actually Works for Dictating Code-Adjacent Text

You are not going to dictate Python or JavaScript. Dictating code syntax is painful and the accuracy on bracket placement and variable names is not reliable enough to be worth it. That is not what this is for.

What works well is everything around the code. Here is a practical list.

Inline comments above complex logic blocks. Say what the code does and why, not just what it does. This is exactly the kind of note that gets skipped when typing feels like work.

Docstrings. Function purpose, parameters, return values, edge cases. Speaking this out takes 30 seconds. Typing it takes 3 minutes and feels like 10.

README updates. When you add a feature, opening the README and dictating a paragraph about it while the context is fresh takes almost no time.

Slack and GitHub comments. Code review feedback, questions on tickets, async updates to your team. These are emails in disguise, and dictation handles them the same way.

The Workflow in Practice

The simplest version: keep VoiceInk running in the background. When you finish a function and want to add a docstring, put your cursor where you want the text, tap the hotkey, and narrate the function behavior in plain English. Done in one take, light edit if needed, move on.

You do not need to switch apps. You do not need to interrupt your flow more than you would for typing. The difference is that speaking a paragraph takes 15 seconds and typing the same paragraph takes 90.

Notes Are the Hidden Opportunity

Beyond documentation, there is a quieter use case: capturing thinking during development. When you are debugging a hard problem and you figure something out, the insight is often gone by the time you finish fixing it. Speaking a quick note into a running text file takes 10 seconds. It creates a record of your reasoning that is useful for documentation later, for post-mortems, for onboarding someone else.

Dictating development notes is not glamorous, but it produces an artifact that pure typing rarely generates because the overhead is just high enough that people skip it.

The Objection About Noise

Open offices and shared workspaces make voice dictation feel awkward. That is real. The workaround is a close-proximity microphone, either a headset or a compact desktop mic that picks up quiet speech without broadcasting it to the room. Speaking at conversational volume, close to the mic, is usually unobtrusive enough that it stops being a concern after the first few sessions.

Documentation is one of those things where the gap between knowing you should do it and actually doing it comes down almost entirely to activation energy. Removing the typing overhead does not make you a better writer, but it makes writing feel cheap enough to do more often. For code documentation, more often is the whole goal.