Typing Practice for Programmers: What Actually Helps

A developer who types 90 WPM in prose will often manage barely half that in code. This is not a personal failing — it is a completely predictable consequence of what code is made of.

Why code is harder to type

Ordinary typing practice trains the alphabet, and the alphabet is the easy part. Code loads its difficulty into everywhere else:

Symbol density. A typical line of JavaScript might be 20–30% non-alphabetic characters. Prose is closer to 2%. Every brace, bracket, semicolon and operator is a shifted or edge-of-keyboard reach.

No word shapes. Prose typing relies heavily on pattern recognition — you type the as a single motion, not three letters. Code has far fewer of these familiar chunks, and identifiers like getUserByIdOrThrow are novel every time.

Constant zone switching. Writing code means jumping between the alphabetic centre of the keyboard and the punctuation edges, repeatedly, with no rhythm to settle into.

Case changes mid-token. camelCase, PascalCase and SCREAMING_SNAKE_CASE mean shift presses inside words, where prose only needs them at the start of sentences.

The reaches worth drilling

Not all symbols are equally costly. These are the ones that most often break rhythm:

Paired delimiters: (), [], {}, <>. The opening and closing characters usually sit on different reaches, often different hands. Practise them as pairs, not as individual characters — the pair is the unit you actually type.

Multi-character operators: =>, ===, !==, ?., ??, ->, ::, &&, ||. Each is a fixed sequence that should become one motion.

The underscore. In Python and many style guides it is everywhere, and it is a shifted pinky reach that almost nobody trains.

Quotes and backticks. Template literals put the backtick — one of the least-used keys in prose — into constant rotation.

Language shapes the practice

The symbol distribution differs enough that practising the wrong language builds the wrong reflexes:

• JavaScript/TypeScript: dense in braces, arrows, and template syntax.
• Python: colons and underscores; far fewer braces; __dunder__ methods.
• SQL: uppercase keywords, which means near-constant shift use.
• HTML: angle brackets and quote pairs, with heavy repetition of closing tags.
• CSS: colons, semicolons and braces in a rigid, highly repetitive pattern.

Practise what you actually write.

What about autocomplete?

A fair objection: modern editors type half of this for you. Why train reaches your IDE handles?

Two reasons. First, autocomplete is unreliable in exactly the places you are slowest — unfamiliar APIs, config files, terminals, code review comments, commit messages, someone else’s editor.

Second, and more importantly, autocomplete requires you to read and select, which is a different interruption. When a reach is automatic, you often type it faster than you could evaluate a dropdown.

Turn autocomplete off while practising, on while working. The goal is removing friction, not typing more characters.

Does this matter?

Beyond a certain speed, thinking dominates typing, and no one writes code at their maximum WPM.

But the friction below that threshold is real. When a symbol reach requires conscious attention, that attention comes out of the problem you were solving. The cost is not the lost seconds — it is the interrupted train of thought, which is expensive to rebuild.

That is the honest case for practising: not to type more code, but to stop typing from intruding on thinking.

Where to start

Begin with your primary language: JavaScript, Python, or SQL each drill real syntax rather than filtered prose.

If a specific reach is your bottleneck, isolate it — symbol practice covers brackets and operators directly, and number practice fixes the number row that most typists never learned.

For a broader session across languages, programming typing practice is the general entry point.