FOR PROGRAMMERS

Typing practice for programmers

Getting fast at typing English prose transfers to writing code less well than you would hope. The vocabulary is different, the rhythm is different, and the words you repeat most are ones that never appear in ordinary writing.

By Hiren Solanki Published 29 August 2026 Updated 2 October 2026

Why prose practice does not transfer

Typing tests are built from ordinary English, which is mostly common short words with predictable letter patterns. Code is not like that.

• The vocabulary is small and repeated constantly. You will type return, function, const and import thousands of times a year, and almost never in an email.
• Identifiers are not words. getUserById is three words with capitals in the middle, which breaks whole-word muscle memory.
• Symbols are everywhere. Braces, brackets, semicolons, arrows and underscores are rare in prose and constant in code.
• The rhythm stops. Prose flows in long runs. Code is short bursts separated by thinking.

The result is that someone comfortable at 80 words per minute on prose often drops noticeably when writing code, and the drop is in exactly the places they never practised.

What is worth practising

The highest-return practice is the vocabulary itself, because the frequency is so lopsided. A short list of keywords accounts for a large share of everything you type.

That last group is worth singling out. Words with unusual letter transitions are where most people lose time, and they are the ones a general typing test will never show you.

The keys that cost programmers most

Code leans on parts of the keyboard prose barely touches, and those are usually the keys people have never deliberately practised.

• The number row and its symbols, especially the brackets and the underscore.
• Right-hand punctuation: semicolon, quotes, slash.
• Shift combinations, since camel case means shifting mid-word rather than only at the start of a sentence.

KEYSTORM only accepts letter keys, so it will not drill your bracket reach. What it will do is tell you which letters are slowing you down, which is where most of the measurable loss is anyway. How the key report works.

Practising with KEYSTORM

Choose the Code word list on the briefing screen before a run. It is built from programming vocabulary across every length the game uses, from three-letter words like api and git up to middleware and keystroke.

Then use the report. After a few runs it will name the letters you actually fumble, and drill mode will build runs loaded with them. Ten minutes a day for a fortnight moves the number more than an hour once a month, because your hands keep improving in the gaps between sessions.

The sequences that only appear in code

Prose practice never gives you these, and they turn up hundreds of times a day. Each is a single motion to a fluent programmer and three separate keystrokes to everybody else.

The pattern across all of them is the right little finger doing work it is unsuited to, usually while holding Shift. The Shift hand rule alone fixes a surprising amount of this, and it is the cheapest change available.

Symbol density varies enormously by language

Where your own work sits on this scale decides how much the symbol keys cost you.

• Heavy. Rust, C++, Perl, Bash and anything with generics or lifetime annotations. Angle brackets, colons and ampersands throughout.
• Middling. JavaScript, Java, C#, Go. Braces and semicolons constantly, but few unusual combinations.
• Light. Python, Ruby. Indentation replaces most of the braces, so keystrokes lean back towards letters and the underscore.

Someone writing Rust all day makes several times as many shifted symbol keystrokes as someone writing Python, and gets proportionally more from practising them.

Identifiers are the real workload

Reading a diff of your own work makes this obvious. The characters you type most are not keywords, they are names, and names have properties prose does not.

They are compound. getUserAccountById is four words with no spaces, so the rhythm that normally comes from the space bar is missing and the name is typed as one long run.

They repeat constantly. A variable used thirty times in a file is thirty repetitions of one motion, so the names worth drilling are the ones in your own codebase.

The case convention decides which keys hurt. camelCase means frequent Shift inside a word. snake_case means the underscore, which is the right little finger reaching for a shifted key. SCREAMING_CASE means holding Shift across a whole token, and it is the one that reliably produces typos.

Where typing stops being the bottleneck

Very little programming is limited by typing speed. The thinking is the slow part, and a developer who types 100 words per minute does not ship more than one who types 65.

What genuinely costs you is different: hesitation on a symbol, breaking your train of thought to look at the keyboard, and typos in strings and identifiers that the compiler does not catch. All three are accuracy problems, and fixing them protects your concentration, which matters more here than raw output.

Two adjacent things are usually worth more than raw typing practice. Learning your editor's navigation properly, since moving around a file is most of what you do. And remapping the keys that hurt, because moving brackets or the underscore somewhere reachable fixes the problem once, with no habit to keep up.