Talking to your editor: how developers actually use dictation

Let's clear this up first: nobody is dictating actual code. Saying "open paren const x equals" out loud is slower and more painful than just typing it, and anyone who tells you otherwise has never tried to dictate a regex. Your fingers own the syntax. They should keep it.

But here is the thing people miss. A real chunk of a developer's day isn't code at all. It's English. And that English is where your voice quietly earns its keep.

The English half of the job

• Pull request descriptions, which everyone writes badly because they write them last and tired.
• Commit messages longer than one line.
• Code review comments, where tone matters and a terse note reads harsher than you meant.
• Slack threads explaining why a thing broke.
• Doc comments and READMEs nobody wants to write.
• The Jira ticket you're putting off right now.

None of that is syntax. It's explaining, in plain language, to another human. And explaining out loud is something most of us are far better at than explaining in writing, because we do it all day in standups and calls.

It's better for the reader, too

A spoken PR description tends to sound like how you'd actually walk a colleague through the change at their desk. "This fixes the race condition in the upload queue. I moved the lock up a level so two workers can't grab the same job." That is clearer than the clipped, half-sentence version most of us type when we just want the thing merged.

Where it gets fiddly, and how to handle it

The obvious objection: technical terms. Generic dictation hears "Kubernetes" and writes "cooper nighties." It mangles your service names, your library names, your acronyms. If every third word is wrong, the cleanup eats the time you saved.

This is the one place a developer really needs more than a plain transcriber. You want something you can teach your vocabulary to, so PostgreSQL, kubectl, and your internal service names come out spelled right every time. Soundfox lets you do exactly that, then cleans up the spoken filler on top, so a rambled explanation lands as a tidy paragraph with the jargon intact.

Keep typing the code. Talk the English around it. That's the split that actually works.