Stop Typing Your Docs: A Developer's Case for Dictation

Developers write more prose than most people realize. README files, inline comments, PR descriptions, Slack updates, architecture notes, tickets. None of this is code, but it takes real time and it is often the first thing that gets skipped when a sprint runs hot.

Dictation does not write your code. But it does make everything around the code significantly faster.

Why Docs Get Skipped

The honest reason documentation does not get written is that writing feels expensive in the middle of building. You are already at the keyboard, you just shipped a function, and now you have to context-switch into prose mode and write a paragraph explaining what it does. The cost is small but the timing is bad, and so it gets deferred until it gets forgotten.

Dictation changes the cost. If you can talk for 20 seconds without touching the keyboard, the inline comment appears and you move on. The context switch is smaller. The interruption to your coding flow is shorter.

What Developers Actually Dictate

The highest-value targets for voice input in a development workflow are:

Inline comments. Speak a sentence or two explaining why a block of code exists, not what it does, the why. This is the comment that saves the next developer, and it takes about eight seconds to dictate.

README sections. Most README files get written in a rush at the end of a project. Dictating them throughout, even rough notes you will clean up later, produces better documentation than nothing.

PR descriptions. Pull request descriptions are consistently bad across the industry. Dictating them takes about 90 seconds and produces a description long enough to be useful.

Slack and email. A lot of developer communication happens in short bursts of text. Dictating these is faster than typing and reduces the friction of async communication.

Meeting notes. Speaking notes into a document during or immediately after a meeting captures more than typing does, because you are not choosing between listening and writing.

Setting Up on Mac

VoiceInk works system-wide, which is the key feature for developers. It does not require you to be in a specific app. You press the hotkey, speak, and the text appears wherever your cursor is, inside VS Code, in a terminal comment, in a browser-based ticket, anywhere.

For code comments specifically, you will want to add the comment syntax manually or by voice. Saying "slash slash space" before dictating a JavaScript comment takes about half a second. Within a few days this becomes automatic.

Accuracy is high enough on modern local models that most short technical phrases land correctly. Proper nouns, library names, and unusual variable names are the main exceptions. Keep a hand on the keyboard for those.

A Simple Workflow for Better Documentation

Pick one part of your codebase that is underdocumented. Write nothing. Instead, open the file, position your cursor above the relevant function, and talk for 30 seconds as if you are explaining the function to a junior developer sitting next to you.

Edit what comes out. It will be rougher than your usual written prose, but it will exist, and existence is the minimum requirement for documentation.

Repeat this every time you finish a meaningful function or module. After two weeks, your documentation habits will have changed more than they would have from any amount of planning to write better docs.

The Bottleneck Is Not Ability, It Is Friction

Most developers know what good documentation looks like. The problem is not knowledge. The problem is that writing prose at a keyboard, when your brain is in code mode, costs more than it seems worth in the moment.

Voice input does not fix the motivation problem. But it reduces the cost enough that the calculation changes. A 20-second spoken comment is easier to justify than a two-minute context switch to typing prose.

If your README is embarrassing and your comments are sparse, this is worth trying before you blame your schedule.