Typing for Programmers: The Keys That Actually Slow You Down
6 min read · Last updated:
A programmer who types 80 words per minute on ordinary prose will often drop to half that on code, and the reason is not conceptual difficulty. It is that code is made largely of the characters prose practice never touches.
English text is mostly home row and the letters immediately around it. Code is full of braces, brackets, angle brackets, underscores, semicolons, equals signs and arrows, all of which live at the edges of the keyboard and most of which require Shift.
Where the time actually goes
These are the characters that consistently cost programmers the most, roughly in order of pain.
| Character | Position | Why it is slow |
|---|---|---|
| { and } | Right edge, with Shift | Little finger reach plus the opposite Shift, on the most-used pair in C-family languages. |
| ( and ) | Number row 9 and 0, with Shift | Long upward reach for the weaker right-hand fingers. |
| _ | Right of 0, with Shift | The furthest common reach on the whole keyboard. |
| [ and ] | Right edge | Right little finger, easily confused with braces by feel. |
| < and > | Comma and period, with Shift | Constant in generics, JSX and arrows; requires Shift on the bottom row. |
| => and -> | Two-key sequences | Combines an awkward reach with a transition most people never drill. |
| | and \ | Above Enter | Right little finger at maximum extension, and the position varies between layouts. |
Practise the transitions, not the characters
Drilling a brace on its own is nearly useless, because a brace never appears on its own. What costs you time is the movement from a letter to a symbol and back, with a Shift press somewhere in the middle.
Drill the sequences you actually type. In practice that means a short list of combinations that appear hundreds of times a day.
- (); and {} as complete units, closing bracket included, rather than as individual characters.
- The arrow forms your language uses: => in JavaScript, -> in Rust, Go and C, both if you switch between them.
- snake_case and CONSTANT_CASE, which chain the underscore reach with ordinary letters.
- === and !== and >=, where two or three symbol keys follow each other directly.
- The string quote plus content plus closing quote cycle, which is where many people lose their place entirely.
Let the editor do the work
Some of the fastest gains in code typing come from not typing at all. This is not laziness: it removes exactly the keystrokes that are slowest and most error-prone.
- Auto-closing brackets mean you type the opening character only. Learn to type through the closing one rather than deleting it.
- Snippets turn a three-letter trigger into a whole block structure.
- Multiple cursors replace a dozen identical edits with one.
- Word-wise navigation with Ctrl or Cmd and the arrow keys avoids arrow-key spamming, which is where a surprising amount of coding time disappears.
A caveat worth stating: relying entirely on completion while never learning the symbol reaches leaves you slow whenever you are outside your configured editor, which includes terminals, remote sessions, code review boxes and interviews.
Does typing speed matter for programming?
Honestly, less than typing enthusiasts claim. Most of a programmer’s day is reading, thinking and debugging, and typing at 120 words per minute does not make you understand a codebase faster.
What does matter is that typing should not interrupt thought. When you have to stop and hunt for a brace, you drop the thread of what you were building. The goal is not raw speed; it is that the mechanical act of writing code stops competing for the attention you need for the actual problem.
Level six of the trainer on this site is real source code, including the bracket, underscore and arrow sequences described above, precisely because prose practice leaves them untouched.