Typing for Programming Work

English prose is about 90% letters and spaces. Source code is not. Braces, parentheses, angle brackets, semicolons, colons, equals signs, dots, quotes and underscores appear at rates that would be bizarre in a sentence, and every one of them is either a shifted key, an outer-column reach, or both.

That changes which fingers are working. Prose loads the index and middle fingers of both hands; code shifts a great deal of the work onto the little fingers, which handle the brackets, the quotes, the semicolon, the colon and the shift key itself — and the little finger is the weakest and least independently controlled of the four.

It also changes what a typing error looks like. A mistyped letter in prose produces a visible misspelling. A mistyped bracket produces code that either fails to parse or, worse, parses into something different from what you meant. The consequence is not proportional to the size of the mistake, which is why accuracy on these characters matters more than accuracy on letters does.

The five-character word convention assumes text with the statistical shape of English prose. Code does not have that shape, so the figure it produces is not comparable to a prose figure.

A line like a nested generic type declaration packs a dozen distinct decisions into a span of characters that the formula scores as three or four words. Meanwhile the same formula would score a run of very common short words far more generously for less work. The result is that a code test will reliably report a lower number than a prose test for the same typist, and the difference is an artefact of the unit rather than a fact about their typing.

The honest way to use that comparison is as a ratio rather than as two scores. If your code figure is far below your prose figure, the gap is telling you about symbol fluency specifically. If they are close, symbols are not your bottleneck and the practice is better spent elsewhere. The mechanics of the formula are set out in how WPM is calculated.

The symbol load is not uniform across languages, and neither is the finger path, which is why this site has a separate drill per language rather than one generic code drill.

Python carries the lowest punctuation load of the common languages and the highest indentation load — a colon before a block and then leading whitespace on the next line, over and over, which is a rhythm no other language produces. JavaScript is dominated by the arrow, which puts an equals and a greater-than adjacent several times a line, and by template literals that need the backtick — the least-typed key on the board. TypeScript adds angle brackets and pipes on opposite hands, so a generic signature demands more shift transitions per character than anything else here. Rust puts a shifted same-finger repeat into ordinary lines. Go is built around one operator typed constantly. SQL is the only one conventionally written in capitals, which turns shift from a tap into a hold.

The corresponding drills — Python, JavaScript, TypeScript, Rust, Go, SQL — each work the pattern that language actually produces, rather than a generic symbol soup.

Typing speed inside an editor is bounded by something other than typing: how quickly you get the cursor where it needs to be.

Two programmers with a thirty-word-a-minute gap between them can finish the same edit in the same time, if the quicker one keeps breaking off to grab a mouse. Every one of those breaks costs the travel out, the travel back, and the moment of re-finding the keys at the end of it. Editing is not a continuous stream of characters; it is a long sequence of short bursts separated by navigation, and the navigation is where most of the time hides.

That makes editor movement — jumping by word, by line, by symbol, by file — the highest-value keyboard skill in programming, and it is a different skill from typing. This is the same argument the site makes about keyboard work generally in shortcuts are the other half of speed, and it applies with unusual force here.

Modern editors complete identifiers, close brackets, and increasingly write whole lines. It is reasonable to ask whether typing fluency still matters.

What completion removes is the long identifier. You type three characters of a variable name and accept the rest, so identifier length stops being a typing cost at all. That is a genuine and large reduction in keystrokes.

What it does not remove is everything structural. Completion does not decide your punctuation for you when you are writing a new expression, does not help with the symbols that open a construct rather than continue one, and reliably gets in the way if you are typing faster than you are reading its suggestions. Auto-closing brackets in particular create a new class of error — a stray closing brace left behind after you typed your own — that only affects people fluent enough to type ahead of the editor.

The net effect is that completion shifts the load from volume to precision. Fewer characters, each of which matters more, which is exactly the direction that makes accuracy work more valuable rather than less.

Symbols first, and specifically the ones your language uses. That is a short list and it responds quickly to concentrated repetition, unlike general speed. Start with the shifted top row if the shifted number row is slow, and with brackets and parentheses if you confuse bracket types under pace — which is common, because three bracket pairs share two physical keys and a shift state.

Then identifier casing, which is a genuinely awkward motor pattern that prose never contains: a capital or a shifted underscore landing mid-word, with none of the pause a space would give you to take it. The camelCase and snake_case drill exists for exactly this.

Then accuracy rather than speed, for the reason given above: a mistyped bracket does not degrade gracefully. The zero-error drill is the relevant discipline.

What is worth least: raising your prose speed. Past a moderate level it does not touch any of the constraints described here, and the hours are better spent on editor navigation.