For programmers
Typing for Programmers: Why Code Feels Slower Than Prose — and How to Fix the Symbol Bottleneck
A fast prose score can hide a slow code score. The bottleneck is usually a specific cluster — brackets, operators, or capitals inside words — and each one has a different fix, starting with a check of what the editor already types for you.
Why code feels slower than prose
A paragraph of English and a line of code ask for different keyboards, in effect. Code is dense in brackets, operators, underscores, semicolons and mixed-case names at frequencies that prose never reaches, and a programmer guide that specialises in this work puts the contrast plainly: a prose speed can be roughly double the same person's real coding speed. Another symbol guide states the underlying reason in numbers — real code is 30 to 40 percent non-alphanumeric characters, while standard typing instruction teaches the letters, the digits and basic punctuation and then stops. The characters that fill a third or more of code are the characters that received no training at all. That gap, not a lack of general typing ability, is what a stumble over a line of code usually is.
It also explains why more prose tests do not fix it. Practising prose strengthens the part of typing that is already strong. The slow part — a shifted brace, a two-character operator, a capital letter in the middle of a word — appears too rarely in prose for prose practice to train it. Programming typing therefore needs its own measure and its own drills, aimed at four things prose tests largely skip: bracket and parenthesis pairs, operator clusters, mixed-case identifiers, and the digit-and-symbol row.
First, verify what your editor already types for you
Before drilling any pair, check a fact about the editor that most practice guides never mention. In Visual Studio Code, the official language-configuration documentation defines brackets as the pairs { }, [ ] and ( ), and defines auto-closing pairs for those brackets plus single quotes, double quotes, the backtick and block comments. When a quote key is typed, the editor creates the pair and places the cursor in the middle. The behaviour is controlled by settings named editor.autoClosingBrackets and editor.autoClosingQuotes, it can be disabled in particular contexts such as strings and comments, and by default a pair is only auto-closed when there is whitespace immediately after the cursor.
That specification changes what practice should train. If the editor inserts the closing brace, the valuable skill is not producing both halves as two separate hunts. The valuable skills are producing the opening character without looking, typing the contents cleanly inside the pair, and moving past or out of the closing character the editor supplied without breaking rhythm — plus knowing what happens in the contexts where auto-closing does not apply, such as inside a string or comment, or when typing directly before another character. A drill that ignores the editor trains a version of the job the reader does not actually do all day. A drill built around the editor trains the real one.
Measure the right thing: three numbers, not one
| Measure | How it is taken | What it tells you |
|---|---|---|
| Prose WPM | A standard typing test on ordinary English text | A ceiling for email, documents and messages; it says little about code |
| Code WPM | Retyping a real function from scratch, without copy-paste | Usually 40–60 percent of prose WPM; below 40 percent points to a symbol or bracket bottleneck |
| Symbol accuracy | Per-character accuracy on the symbol row during code practice | Below 95 percent means the keys are still being guessed at, not typed |
Those three numbers turn a vague feeling — code is slow — into a diagnosis that points at a fix. A healthy prose score beside a code score in the normal 40 to 60 percent range usually means the symbol work is proportionate and general fluency is the remaining lever. A code score below 40 percent of prose is a specific accusation: brackets and symbols, not letters, are eating the time. And symbol accuracy below 95 percent settles the argument about method — at that level the fingers do not yet know where the keys are, so speed work is premature and accuracy work, at whatever slower pace it requires, is the correct next step.
The three bottlenecks, compared
Bracket pairs. Code uses ( ), { }, [ ] and < > as matched pairs, and pair fluency is a placement skill prose never builds. Symbol guides consistently rank curly braces and square brackets among the slowest characters for developers: braces require Shift and sit on the right side of the keyboard, and brackets ask the right hand to stretch away from the home position. The fix is pair work — empty pairs typed as single gestures, then nested combinations — adapted to the editor check above: opening fluently, filling accurately, and exiting cleanly.
Operator clusters. Code is full of two- and three-character units that function as one symbol: =>, ==, !=, <=, >=, ::, ?., && and ||, among others. Each cluster has its own finger choreography, often involving Shift in the middle, which is why a cluster can stall a line even when each character in it is known separately. The slowest-symbols lists return to the same clusters for the same reason — the arrow function, the pipe, the ampersand pair, angle brackets, the backtick used for template literals, and strict inequality all combine high frequency in modern code with a Shift dependency.
Mixed-case identifiers. Prose capitals arrive at the start of a sentence, where the Shift key is a single, predictable event. Code capitals arrive in the middle of words: camelCase, PascalCase, snake_case and constant-style names each impose a different rhythm, and the skill is releasing or holding Shift mid-word without breaking the word into two separate motions. Identifier practice should use real names — the kind that appear in actual code, such as getUserById or parseQueryString — because the case transitions in invented short words do not resemble the transitions in real ones.
A two-week diagnostic and drill procedure
- Take the three measures on day one. Record a prose score, retype a real function of about twenty lines from scratch and record that score, and note symbol accuracy. Write all three down; the retest only means something against the same tasks.
- Check the editor before drilling pairs. Confirm whether auto-closing for brackets and quotes is on, and practise one line with it in mind: open pairs, type inside them, and move past the supplied closing characters.
- Spend five minutes on operator drills. Choose the five operators used most in the main language, and repeat each cluster until the fingers stop searching between its characters.
- Spend ten minutes retyping real code. Use a short function from a respected project or the language's standard material, typed from scratch without copy-paste, slowly enough that a mistyped bracket is noticed rather than carried.
- Spend five minutes writing a plain-English comment or explanation. Describing something just built, in full prose with no shortcuts, keeps ordinary writing speed from decaying while symbol speed climbs.
- Repeat daily for two weeks, then retest the same three measures. Compare code WPM as a percentage of prose WPM, and symbol accuracy against the 95 percent line, before deciding what the next two weeks should target.
What success looks like: the retest shows code speed moving toward or into the 40 to 60 percent of prose range, symbol accuracy at or above 95 percent, and — the practical test — a familiar line of code typed without a pause at its brackets, operators or capital letters.
Choose your drill set by language: a decision framework
If the main language is JavaScript or TypeScript, the drill set is braces for blocks and destructuring, brackets, the arrow cluster, template literals with the backtick, optional chaining and nullish coalescing, and generics with angle brackets — the patterns those languages repeat in file after file. If the main language is Python, braces matter far less and the set changes accordingly: colons after control structures, brackets and braces inside comprehensions and dictionaries, f-string forms, and asterisk forms such as *args and **kwargs. If the work is Rust, Go, shell or SQL, build the set from that language's documented operators instead of borrowing another language's list — scope and channel operators, pointers, pipes and redirections, and comparison forms differ enough that a borrowed drill set trains yesterday's bottleneck. The rule underneath every branch is the same: the five most frequent clusters in the code actually typed each week are the drill set, and the keyword sprint follows the same rule — the ten keywords of the working language, typed as a one-word drill until they are automatic, because a slow keyword is typed every few seconds.
Questions programmers ask about typing
How fast is fast enough? The goal described by programmer-focused guidance is not a headline number but the point where the keyboard stops being the bottleneck — commonly framed as roughly 50 to 70 words per minute on prose together with fluency on the symbol-heavy material. A fast prose score with slow symbols does not meet that description.
Should closing brackets be drilled at all if the editor inserts them? Yes, but differently: drill opening them without looking, typing inside them accurately, and moving past the supplied closing character. Also keep some pair practice for contexts where auto-closing is disabled or does not trigger, such as certain string and comment contexts or typing immediately before another character.
Why does accuracy come before speed here? Because the diagnostic says so. Symbol accuracy below 95 percent identifies guessing, and speed built on guessed key positions has to be unlearned. Slowing down until the cluster is clean, then letting speed return, is the route the practice guidance recommends for a plateau as well.