Typing for Programmers

Programmers routinely find their typing speed collapses when they type code. This is not imagination and it is not a skill problem — it is a character distribution problem.

Why code is slower

English text is roughly 99% lowercase letters, spaces and the occasional comma. Code is not:

• Symbols everywhere — { } ( ) [ ] < > ; : = + - * / & | ! ? # $ @ _
• Constant shift key — most symbols are a shifted number or a shifted punctuation key
• Little fingers overloaded — brackets, braces, quotes, colons, underscores all live on the outer columns
• camelCase and snake_case — capitals and underscores mid-word, where your hands expect a space
• No predictable word shapes — getUserById is not a word your hands have a movement for

The keys you use most in code are precisely the keys typing practice never drills. A test drawn from the 200 most common English words will never once ask you to type a curly brace.

What to actually drill

Rather than general speed practice, drill the specific things:

The symbol row. ! @ # $ % ^ & * ( ) — as shifted numbers, without looking. Most developers hunt for at least half of these.

Bracket pairs as single movements. (), [], {}, "", '' — practise them as one gesture, not two keys. Your editor auto-closes them, which is exactly why you should still know them.

The awkward ones. _ (shift-hyphen, right little finger), |, ~, \, < and >. These are the slowest keys for nearly everyone.

Right little finger endurance. In most languages it handles ;, :, ', ", [, ], \, Enter and Backspace. It is the weakest finger doing the most work. See the finger chart.

Your own language's idioms. => in JavaScript, :: in C++ and Rust, -> in Go and Python type hints, </> in JSX. Whatever you type a hundred times a day.

Does typing speed matter for programmers?

The honest answer is less than typing enthusiasts claim and more than the standard rebuttal admits.

The usual argument is that programming is thinking, not typing, and you spend most of your time reading. Both true. Nobody ships faster because they type at 120 WPM.

But the standard rebuttal quietly assumes typing is effortless, and for many developers it is not. The cost shows up in ways that do not look like typing speed:

• Descriptive names lose to short ones when long names are annoying to type
• Comments and commit messages get shorter than they should be
• Exploratory rewrites feel expensive, so a mediocre first structure survives
• Attention leaks to your hands during the exact moment you were holding a design in your head

That last one is the real cost. Not seconds — interruptions to thought.

A reasonable target

60 WPM on prose, with symbols automatic. Past that, effort is better spent on your editor than your fingers.

If you type at 40 WPM and hunt for braces, you are paying a real tax. If you type at 70 with fluent symbols, typing has stopped being your bottleneck and more practice is a hobby.

The higher-leverage things

For most developers these beat typing practice outright:

• Editor fluency — multi-cursor, jump-to-symbol, refactor shortcuts. Editing beats retyping.
• Snippets and autocomplete — the fastest keystroke is the one you skip.
• Not looking at the keyboard. If you still look down, that costs you more in code than in prose, because your eyes are needed on indentation, brackets and errors.

How to practise

Type real code, not prose. Retype a file from a project you know, or work through something in your actual language — the point is meeting your real character distribution.

Then use ordinary typing practice to keep your base speed up, and drill symbols separately. Test yourself on prose for a baseline; just do not expect the number to describe your coding speed.