Dictating Code Comments: A Developer's Honest Take

Every developer knows the feeling. You just wrote a function that took two hours to get right. It's clever, a little delicate, and will confuse the next person who reads it, including you in three months. You should write a comment. You don't write the comment. You move on.

The reason isn't laziness. It's friction. Switching mental modes from code to prose is hard enough. Adding the physical overhead of typing out a paragraph makes it easier to skip.

Voice dictation doesn't solve the mode-switching problem, but it cuts the physical overhead down to nearly zero.

What Developers Actually Use Dictation For

Code itself is a bad target for voice dictation. Syntax is unforgiving, and speaking punctuation out loud gets old fast. But prose around code is a different story, and there's more of it than most developers admit.

Documentation. README files. PR descriptions. Inline comments. Commit messages. Slack threads explaining an architectural decision. These are all plain English, and they take real time when typed.

A decent PR description might run 150 to 300 words. Typed, that's two to four minutes if you're thinking as you go. Dictated, it's 90 seconds, and the result often reads better because you're explaining it the way you'd explain it to a colleague out loud.

The Workflow That Actually Works

The setup that works best is keeping dictation available as a quick press rather than a mode you have to enter. VoiceInk handles this by letting you hold a key, speak, and release. Your words appear at the cursor wherever it sits, whether that's a comment line in your editor, a GitHub text field, or a Notion doc.

A practical flow: write the function, then before moving to the next task, press the dictation key and narrate what the function does and why. Speak it like you're explaining it to someone who just joined the team. Release the key. Done. The comment exists and it took 20 seconds.

For README sections and longer docs, dictating a rough pass first and editing afterward is faster than writing from scratch. The dictated version gives you structure and content. The editing pass gives you precision.

Commit Messages and PR Descriptions

These are the two places where developers consistently write worse than they think. Commit messages become "fix bug" and "update styles." PR descriptions become one sentence with no context.

Part of that is time pressure. Part of it is that typing a real description feels like overhead when you just want to merge and move on.

Dictating a commit message takes about ten seconds. Speaking two or three sentences about what changed and why, then moving on. The transcript might need a small cleanup, but you end up with messages that are actually useful when someone runs git log six months later.

Note-Taking During Problem-Solving

This is the use case that surprised me most when talking to developers who use dictation. When you're deep in a debugging session, your mental model of the problem is rich and temporary. If you step away and come back, you rebuild that context from scratch.

Dictating a quick note while you work, not a formal document, just a spoken stream of what you're seeing and what you've tried, captures that context cheaply. A 60-second voice note turned into text is searchable, pasteable, and way better than nothing.

The Honest Limitation

Dictation won't replace typing for code. Variable names, brackets, function calls, these require keyboard input. But the prose layer around code, which is larger than most developers track, is a legitimate target.

If your documentation is thin because writing it takes too long, dictation is worth trying for a week. The investment is one keyboard shortcut and a willingness to talk to your computer. The return is comments that actually exist.