Why Typing Code Is Harder Than Typing Prose
Symbols, casing and structure make code a different skill. Train it directly.
Prose is predictable, code is not
English is highly redundant. After typing 'th' your fingers can begin 'e' before you have consciously read it, because letter sequences are so predictable that experienced typists run partly on autocomplete.
Code removes that. Identifiers are arbitrary, symbol sequences follow no phonetic pattern, and there is no equivalent of a common letter pair to coast on. Every character has to be read and typed deliberately, which is why fast prose typists often feel unexpectedly slow on code.
Casing changes everything
In prose, capitals appear at the start of sentences and in names — perhaps two percent of characters. In code, camelCase and PascalCase put them mid-identifier constantly, and every one requires a shift while your fingers are mid-flow.
This is why shift technique matters far more for developers than for writers. A habit that costs a writer a few awkward moments per paragraph costs a developer several per line.
Structure and whitespace
Code carries meaning in its layout. Indentation, line breaks and alignment are part of the text, and a typing test that ignores them is not measuring the real task.
Our code mode handles indentation the way an editor does: press enter and the leading whitespace on the next line is filled in for you, because no real editor makes you type it manually. You are being measured on the characters you would actually press.
What this means for your practice
Practise the language you write. The symbol distribution differs sharply between languages — Rust leans on angle brackets and ampersands, Python on colons and underscores, JavaScript on arrows and braces — and practising the wrong distribution builds the wrong reflexes.
Expect your code WPM to sit well below your prose WPM, often by thirty percent or more. That is not a deficiency to fix; it is the honest measure of the task. Track it separately and compare it only against itself.
Autocomplete changes which skill matters
Modern editors complete identifiers, close brackets and suggest whole lines, which genuinely reduces how much you type. It is a fair objection to code-typing practice, and it is worth taking seriously.
What it changes is the distribution rather than the total. Autocomplete is best at long identifiers and worst at the punctuation between them, so what you are left typing by hand is disproportionately the symbol-dense part — exactly the material that is hardest and least practised.
What to practise when the editor helps
Given that, the highest-value practice is the punctuation an editor cannot guess for you: operators, closing sequences you type through rather than accept, and the number row.
There is a second-order effect too. When typing is effortful, people accept a wrong suggestion rather than type the right thing, because correcting it feels expensive. Fluency removes that pressure, and the code gets slightly better for reasons that have nothing to do with speed.
Put it into practice
Frequently asked questions
Why am I so much slower at typing code?
Code lacks the statistical predictability of prose, capitalises mid-word constantly, and is dense with shifted symbols and number-row reaches. A gap of thirty percent or more against your prose speed is normal.
Do I have to type the indentation myself?
No. In code mode, leading whitespace after a newline is filled in automatically, matching what a real editor does. You are scored on the keystrokes you would genuinely make.
Does practising one language help with others?
Partly. Shared symbols like brackets and semicolons transfer well, but each language has its own distinctive character distribution, so practising the language you actually write gives the best return.