Why code does not type like prose

Four things separate a line of code from a line of English, and every one of them works against the rhythm a typing test rewards.

Symbol density

Prose is mostly lowercase letters with a comma every so often. Code is full of characters that live off the home row and behind the shift key. On a US QWERTY keyboard the fragment if (x === y) { is fourteen characters, three of which — the two parentheses and the opening brace — require shift. Fourteen characters of ordinary English prose typically require none.

Capitalisation is load-bearing

In prose a missed capital is a blemish. In code, userName and username can be two different things, and getting it wrong is a bug rather than a typo. Every camelCase or PascalCase identifier puts a shift press in the middle of a word, in a position no English word ever puts one.

There is no sentence rhythm to fall into

Fluent typing runs on sequences your hands have made thousands of times. In the largest published typing study, the fastest participants overlapped 40 to 70 percent of their keystrokes, pressing the next key before releasing the last (Dhakal, Feit, Kristensson and Oulasvirta, CHI 2018). That overlap develops on familiar letter patterns. Code has frequent sequences of its own — the arrow, the double colon, the closing paren followed by a semicolon — but they are short, punctuation-heavy, and surrounded by text that does not flow the way a sentence does.

Your hands keep leaving the alphabet

Writing code means reaching for the number row, the bracket keys, the slash and the underscore, and interleaving those reaches with navigation, selection and deletion that are not typing at all. A prose test never asks for any of it.

Why your prose WPM overstates your coding speed

The five-characters-per-word convention that every typing test uses gives no discount for difficulty. A semicolon counts exactly as much as the letter E; an opening brace counts exactly as much as a space. That is the right convention — it is what makes results comparable across different texts, tests and languages — but it does mean a WPM figure treats the hardest character on your keyboard and the easiest as identical units of work.

WPM also cannot see the shift key. Keyboardo's engine counts printable characters and backspaces; modifier keys are not keystrokes as far as any typing metric is concerned. Type const userName = getUser(id); and you have produced 29 characters, which the convention scores as 5.8 word-equivalents — while your hands actually pressed shift four times to do it, twice for the capitals and twice for the parentheses.

Put those together and a 90 WPM prose typist is simply not a 90 WPM code typist. The gap is not a sign that anything is wrong with your typing. It is the measurement doing exactly what it says on the label, over text it was never designed to describe.

What autocomplete does to the measurement

In a real editor, much of what appears on screen was never typed. Completion turns a fifteen-character identifier into three characters and a tab. Snippets expand a keyword into a block. Auto-pairing inserts the closing bracket the instant you type the opening one. A formatter fixes your indentation when you save.

This makes characters-per-minute close to meaningless as a measure of coding output, and it fails in both directions at once. It undercounts the work, because reading, thinking and navigating produce no characters. It overcounts the typing, because a large share of the characters on screen came from a single keystroke. There is no published measurement linking a programmer's words per minute to what they produce, and given how much of the visible text is machine-generated, it is not obvious what such a measurement would be measuring.

What Keyboardo's punctuation and numbers toggles actually add

This section is deliberately specific, because code-typing practice is easy to oversell. Punctuation and numbers are two independent switches on word and time tests. Precisely what they do:

  • Punctuation decorates the generated words with sentence punctuation. Some words are capitalised; some pick up a trailing full stop, comma, exclamation mark or question mark; some are wrapped in double quotes; and occasionally two words are joined with a hyphen.
  • Numbers mixes standalone numeric tokens of one to four digits into the stream. Number tokens are never decorated with punctuation.

That is prose punctuation, not code punctuation. It will train the shift reaches, the number row, and the accuracy cost of a capital letter turning up where you did not expect one. It will not give you brackets, braces, angle brackets, semicolons, operators, underscores or arrows, because what the toggles decorate are English, French and Arabic word lists rather than source code.

Two consequences worth knowing. Both toggles make a result ineligible for the leaderboards, which accept only English 1k tests with punctuation and numbers switched off — so this is practice mode, not competition mode. And your WPM will drop, which is the point rather than a problem: the score is lower because the text is harder, in exactly the way it is when you type code.

What is actually worth practising

Ranked by how much of the difficulty above they address. This is reasoning about the mechanics, not a finding from a study — nobody has measured the effect of any of it on programming specifically.

  1. The symbol reaches, without looking. Brackets, braces, quotes, the slash, the underscore. If your eyes drop to the keyboard for a curly brace, that is a pause every time you open a block, and code is dense in blocks.
  2. The number row. Typing prose fluently does not carry over automatically to digits, because the number row gets a fraction of the practice the letters do. Keyboardo's numbers toggle addresses this directly and is the most code-relevant setting on the site.
  3. Accuracy on identifiers. A typo in prose is still legible; a typo in an identifier is a compile error, or in a dynamically typed language a silent bug. This is the one place where the accuracy-first argument is not merely an argument about scoring.
  4. The sequences your own language uses most. No general typing test covers the arrow functions of JavaScript, the double colons of C++, the significant indentation of Python or the sigils of Perl. Practise those where they live, in your own editor, on real code.
  5. The parts that are not typing. Navigation, multiple cursors, jump-to-definition, rename-symbol. On most days these save more keystrokes than any plausible speed gain would.

What typing fluency actually buys a programmer

Not throughput. The bottleneck in writing software is rarely the rate at which characters can be entered, and claiming otherwise would require a measurement nobody has made.

What it plausibly buys is attention. When the mechanics of getting a thought onto the screen stop competing for working memory, more of your attention is left for the problem you were actually thinking about. That is a claim about attention rather than about output, and it is offered here as reasoning rather than as a measured result — which is the honest status of every "typing makes you a better programmer" argument you will read, including this one.

If you want to see the size of the effect on your own hands, run a 60-second test with punctuation and numbers off, then run one with both on. The gap between the two numbers is a rough measure of how much of your fluency depends on the text being easy.