You write code for a living, but half your day is commit messages, PR descriptions, Slack explanations, and docs. That's where voice helps.
You're a senior backend engineer. VS Code is your home. But between the actual coding, there's a surprising amount of English that needs writing.
Your team does async standups in a Slack channel. You know what you did yesterday and what you're doing today, but translating that into a typed message always takes longer than it should. You end up rewording things three times. Instead, you hold the Steno hotkey and just say it. Yesterday's migration fix, today's API refactor, the blocked dependency. Done in twenty seconds. You skim it, fix a typo, post.
"Yesterday I fixed the database migration issue on the payments service and got it deployed to staging. Today I'm refactoring the authentication middleware to support the new OAuth flow. Blocked on the DevOps team to provision the new Redis cluster."
Yesterday I fixed the database migration issue on the payments service and got it deployed to staging. Today I'm refactoring the authentication middleware to support the new OAuth flow. Blocked on the DevOps team to provision the new Redis cluster.
You shipped a fix yesterday and opened a PR right before EOD with a one-line description. Now you need to write it up properly before anyone reviews it. The what, the why, the testing steps. You know all of this because you just wrote the code. But typing it into the GitHub PR template feels like busywork. You click into the description field, hold the hotkey, and talk through the change like you would explain it to a teammate at your desk. Two minutes of talking gives you a thorough PR description that would have taken ten minutes to type and format.
"This PR fixes the race condition in the payment webhook handler. Previously, when two webhooks arrived within the same millisecond, both would attempt to update the order status simultaneously, causing duplicate charge entries. The fix adds an advisory lock on the order ID before processing. I tested this locally by simulating concurrent webhook deliveries with a script. No changes to the public API."
This PR fixes the race condition in the payment webhook handler. Previously, when two webhooks arrived within the same millisecond, both would attempt to update the order status simultaneously, causing duplicate charge entries. The fix adds an advisory lock on the order ID before processing. I tested this locally by simulating concurrent webhook deliveries with a script. No changes to the public API.
You're reviewing a teammate's PR. The code works, but there's a subtle issue with how they're handling connection pooling, and a spot where an early return would make the logic cleaner. Typing out a thoughtful review comment takes forever because you're trying to be helpful without sounding critical. With Steno, you just talk through your thinking. "This works, but if we add an early return here for the nil case, the rest of the function gets a lot easier to follow." You leave four comments in six minutes. Normally this review would sit in your tabs for half the day because the typing felt like too much effort.
The team needs an ADR for why you chose Postgres advisory locks over a distributed lock service. You have strong opinions about this, but writing them in a structured doc feels like pulling teeth. You open Notion, hold the hotkey, and just start explaining it the way you would to a junior engineer asking you at lunch. Why advisory locks are simpler for your use case, why Redis-based locks add operational overhead you don't need, what the tradeoffs are. Five minutes of talking gives you a solid first draft. You spend another ten cleaning it up, adding headers, and linking to the relevant GitHub issues. The hard part, getting the reasoning out of your head, took five minutes instead of an hour of staring at a blank page.
Your PM pings you: "Why are some users seeing duplicate charges?" You know exactly what happened, but explaining it without jargon to someone who doesn't know what a race condition is takes careful phrasing. Typing it out, you'd rewrite every sentence twice. Instead you hold the hotkey and explain it like a story. "So here's what's happening. When a customer clicks pay, their bank sends us a confirmation. Sometimes the bank sends two confirmations within a fraction of a second. Our system was treating each one as a separate payment. The fix we shipped this morning makes sure we only process the first one." Clear, no jargon, and it took you thirty seconds instead of five minutes of agonizing over word choice.
Here's what's happening. When a customer clicks pay, their bank sends us a confirmation. Sometimes the bank sends two confirmations within a fraction of a second. Our system was treating each one as a separate payment. The fix we shipped this morning makes sure we only process the first one.
You're deep in a refactor and making a series of small, focused commits. Each one needs a message that actually says something useful, not just "fix stuff" or "WIP." But context-switching from code brain to English brain for every commit breaks your flow. You stay in VS Code, hold the hotkey at each commit point, and just say what you did. "Extract webhook validation into its own middleware." "Add retry logic for failed Stripe API calls with exponential backoff." "Remove deprecated payment gateway adapter." Twelve commits over two hours, each with a clear message. Your git log actually tells a story.
You have four Jira tickets that need status updates before you log off. Two are in progress, one is blocked, one you finished today. Normally you'd put this off until tomorrow morning and then forget half the context. Instead you open each ticket, hold the hotkey, and dictate a quick update. "Finished the advisory lock implementation and opened a PR. Waiting on review from the platform team. Should be ready to merge tomorrow." Four tickets updated in three minutes. You close the laptop and actually leave on time.
Next time you're about to type a commit message, hold the Steno hotkey and just say what you changed. It's the smallest possible experiment. One sentence, no context switch. You'll notice how much faster it is to stay in flow.
Before your next code review, talk through the PR description instead of typing it. Explain the change like you would to a teammate. You'll write better descriptions because speaking encourages you to include the why, not just the what.
Next time someone asks "what happened?" in Slack, hold the hotkey and explain it out loud. Talking forces you to simplify. You'll communicate more clearly and spend less time rewriting.