Dictating Code Comments: A Developer's Honest Take

Every developer knows comments matter. Every developer also knows they're the first thing cut when time gets short. The problem isn't intention. It's that stopping to write a paragraph of explanation while you're in the middle of solving something feels expensive in a way that's hard to justify in the moment.

Dictation doesn't make you want to write documentation. But it makes the act fast enough that you stop skipping it.

Where Voice Actually Helps in a Dev Workflow

The strongest use case isn't writing code. It's capturing the thinking around code. The why, not the what.

When you've just spent 40 minutes debugging a non-obvious issue and finally found the fix, you understand the problem better than you ever will again. That's the moment to capture it. Speaking a three-sentence explanation of what the bug was, why the fix works, and what anyone touching this later should know takes about 20 seconds. Typing the same thing takes longer, which means it usually doesn't happen.

The same applies to architectural decisions, edge cases you've accounted for, and anything that will confuse your future self. Voice is fast enough that capturing it while the context is fresh becomes a reasonable habit rather than a discipline you have to force.

Practical Setup for Developers

VoiceInk runs locally on your Mac, which matters in a development context. Your code, your architecture notes, your internal tooling decisions aren't going to a third-party server. You press a key, speak, and the text appears wherever your cursor is. That works in VS Code, in Xcode, in a terminal note, in a Notion doc, anywhere.

For inline comments, the workflow is: write the code, then move to the comment line and dictate. For longer documentation blocks, dictate a rough version first, then clean it up. The cleaning is fast because the thinking is already there.

What to Dictate and What to Type

Some things are still faster to type. Short variable names, specific syntax, anything with a lot of special characters. Dictation isn't a replacement for your keyboard when you're in flow on a problem.

But for anything prose-adjacent, the math changes. README sections, PR descriptions, internal wiki pages, Slack messages explaining what you just merged and why: these are all places where speaking produces a better result in less time than typing.

PR descriptions deserve a specific mention. Most developers write one or two sentences. If you dictate it, you'll write four or five, which means reviewers have the context they need and the back-and-forth gets shorter. That's time saved downstream.

Note-Taking During Debugging

One use case that's underrated: talking through a problem while you investigate it. Not for the transcript's sake, but because articulating what you're seeing often reveals what you're missing. If you do capture the audio or the dictated notes, you also have a record of your debugging process, which is occasionally useful and occasionally the thing that saves you an hour.

Developers who already do rubber-duck debugging know the principle. Voice capture just means the duck takes notes.

Starting Small

If you want to try this without changing your whole workflow, start with PR descriptions. Next time you open a pull request, press a dictation key and explain the change out loud as if you're telling a colleague what you did and why. Clean it up and submit. That's it. One habit, one place, and you'll get a sense of whether voice capture has a place in how you work.