The idea of dictating code sounds absurd. Saying "open curly brace, const user equals await fetch, open parenthesis, single quote, slash API slash users" is clearly slower and more error-prone than just typing it. Nobody is suggesting you dictate raw syntax.
But writing code is only part of what developers do. A significant portion of a developer's day is spent writing natural language: code comments, commit messages, pull request descriptions, documentation, Slack messages, Jira tickets, code review feedback, design documents, and emails. These are all tasks where voice typing is dramatically faster than keyboard typing, and they collectively consume a surprising amount of engineering time.
Where Voice Dictation Fits in a Developer's Workflow
Code Comments and Docstrings
Good code comments explain why, not what. They describe the reasoning behind a design decision, the edge case that motivated a particular check, or the business context that a future developer will need to understand the code. These explanations are inherently verbal -- they are the things you would say to a colleague looking over your shoulder.
Dictating comments is natural because you are literally explaining your code out loud. Position your cursor above the function, hold your Steno hotkey, and say: "This function retries failed API calls with exponential backoff. We cap at five retries because the upstream service's SLA guarantees recovery within 30 seconds, and five retries with exponential backoff covers roughly 31 seconds of total wait time." Release the hotkey, and you have a comment that a future developer will actually appreciate.
Compare that to typing the same comment. Most developers would write something like "Retry with backoff, max 5" because typing out the full explanation feels like too much effort. Voice removes that friction, and the result is better-documented code.
Commit Messages
The eternal struggle of every development team: getting developers to write meaningful commit messages. The problem is not that developers do not know what they changed or why. It is that typing out a detailed commit message after you have just spent an hour debugging a gnarly issue feels like an unnecessary chore.
With voice typing, a commit message takes five seconds instead of thirty. Open your terminal or Git client, start the commit, hold the hotkey, and say: "Fix race condition in the WebSocket reconnection handler. The previous implementation could attempt to send messages on a closed socket if a reconnect was triggered while a send was in flight. Added a message queue that buffers outgoing messages during reconnection." Release, commit, done.
That is a commit message that will genuinely help someone six months from now. And it took less time than typing "fix websocket bug."
Pull Request Descriptions
Pull requests need context. Reviewers need to understand not just what changed but why, what alternatives were considered, what the testing strategy is, and what risks to watch for. Writing all of this out by hand is tedious, which is why so many PRs have descriptions that say "See ticket" or nothing at all.
Dictating a PR description is like briefing a colleague. Hold the hotkey and explain: "This PR migrates our authentication flow from session-based to JWT tokens. The main motivation is to support our new mobile app, which cannot maintain server-side sessions. I have updated the login endpoint to return a JWT, added middleware to validate tokens on protected routes, and updated the logout flow to use a token blacklist with a 24-hour TTL. The migration is backward compatible -- existing sessions will continue to work for 30 days, after which they will be forced to re-authenticate."
That took about 30 seconds to speak and would have taken 3 minutes to type.
Slack and Team Communication
Developers spend a lot of time in Slack. Answering questions, providing context on issues, discussing architecture decisions, giving updates in standups. These are all natural language tasks where voice typing shines.
Steno works in Slack because it works everywhere -- it pastes text at the cursor, so any application that accepts paste is supported. Click into a Slack message, hold your hotkey, speak your response, release. Your message appears, properly punctuated and ready to send.
This is particularly valuable for those long Slack threads where you need to explain a technical concept or provide detailed context. Instead of spending five minutes typing out a multi-paragraph explanation, you can speak it in 90 seconds.
Documentation
Documentation is the task that developers universally agree is important and universally avoid doing. The friction is almost entirely in the writing itself. You know how your system works. You could explain it to a new team member in ten minutes. But writing it down? That takes an hour of staring at a blank page.
Voice typing removes the blank page problem. Open your documentation file, hold the hotkey, and explain your system as if you were onboarding a new developer. You will produce a rough but comprehensive draft in minutes instead of hours. Then do a quick editing pass to clean up structure and formatting.
The quality of dictated documentation is often surprisingly good because it captures the explanatory style you would naturally use when teaching someone, rather than the terse, over-compressed style that developers tend to write in.
Practical Tips for Developers
Think Before You Speak
Take a few seconds to organize your thoughts before pressing the hotkey. The best dictation comes from a clear mental outline, not from thinking out loud. Thinking is silent. Speaking is for output.
Dictate in Chunks
For longer content like documentation or design documents, dictate one section at a time. This gives you natural breakpoints to review and adjust before moving on.
Use Your Normal Technical Vocabulary
Whisper handles technical terms remarkably well. Say "API endpoint," "WebSocket," "OAuth," "Kubernetes," "PostgreSQL," or "Redis" and it will transcribe them correctly. You do not need to dumb down your language or spell things out.
Code Review Comments
Code review is another high-value application. Instead of typing terse comments like "why?" or "this could be cleaner," dictate fuller feedback: "I think this would be more readable if we extracted the validation logic into its own function. The current approach nests three levels of conditionals, which makes it hard to follow the happy path. A dedicated validate function would also make it easier to add new validation rules later without increasing the nesting depth."
Better code review feedback leads to better code and fewer review cycles. The time investment in dictating a thorough comment pays for itself immediately.
Why Steno Works for Developers
Steno was built by developers. It works in terminals, in VS Code, in web-based tools like GitHub and Jira, in Electron apps like Slack and Discord, and in every other application developers use daily. It runs as a lightweight menu bar app that uses minimal resources. It does not interfere with your IDE's keyboard shortcuts because it only listens when you are holding your chosen hotkey.
The hold-to-speak model is critical for developer workflows. You maintain precise control over when the microphone is active. There is no risk of accidentally dictating a private conversation into a code comment or a Slack message. Press, speak, release. That is the entire interface.
Download Steno free at stenofast.com. Start with your next commit message. You will find yourself reaching for the hotkey for everything you write that is not code.