Typing Speed for Programmers: How Much Does It Matter?
Typing speed matters less to programmers than to almost any other keyboard job. In two field studies of how developers spend their time, actually editing code took only about 5% of the working day, while reading and understanding code took 58% to 70%. So the useful goal for a programmer is comfortable, accurate typing, especially on symbols, rather than a high WPM score. We also looked for a study of programmers' typing speeds and found none, so we will not give you a benchmark such as "programmers should type 80 WPM". Anyone who does is guessing.
What the studies found
Two published field studies measured how developers divide their time by recording their computer activity:
- Minelli, Mocci and Lanza (2015), I Know What You Did Last Summer, recorded about 740 development sessions by 18 developers, around 200 hours and 5 million IDE events. They found that program understanding took roughly 70% of the time, editing roughly 5% and navigation roughly 4 to 5%, with the rest spent on interface handling and time outside the IDE.
- Xia and colleagues (2018), Measuring Program Comprehension: A Large-Scale Field Study with Professionals, followed 79 professional developers on 7 real projects, 3,244 working hours in all, and recorded activity across many applications instead of one IDE. They reported that developers spend up to 58% of their time on program comprehension. Across five of the projects the averages were 57.62% comprehension, 23.96% navigation, 13.40% other and 5.02% editing. They also found that senior developers spent a significantly smaller share of their time on comprehension than junior developers.
The two studies disagree on the exact comprehension figure, and Xia and colleagues point out why the earlier one is limited: its dataset was small and mostly from three PhD students working in one IDE. Both agree on the important part: editing is a small slice of a developer's time.
What that means for typing speed
Take the most generous reading: assume all of that roughly 5% of editing time is pure typing, and that you double your typing speed. You would save about half of it, so about 2.5% of your working time at best. This is our own back-of-the-envelope arithmetic, and the real saving is probably smaller, since editing time includes thinking as well as typing. The point stands: for a developer, going from a comfortable typing speed to a very fast one is a small gain compared with how you spend the other 95%.
That is a different situation from jobs such as data entry or transcription, where typing is the work. See data entry typing tests for that case.
Where typing still matters for programmers
The studies do not say typing is irrelevant. Three things are worth caring about. They are our reasoning, not findings from those studies:
- Accuracy on symbols. Code is dense with brackets, quotes, operators and punctuation, and a wrong character can break a program. Clean typing of symbols saves debugging time.
- Not breaking your train of thought. If typing is automatic, you can keep your attention on the problem. The idea behind muscle memory is that practised movements need less attention.
- Comfort over long sessions. Programmers sit and type for hours. A good desk setup matters more than a few extra WPM. See our posture and wrist pain guide.
There is one more inference. In the Xia study, navigation took nearly a quarter of developers' time, far more than editing. Learning your editor's keyboard shortcuts for moving around code may therefore pay off more than raw typing speed. The studies did not test that, so treat it as a hypothesis worth trying.
Practising code typing on FreeTyper
- The speed test has a code text type made of programming snippets. Expect a lower WPM than on words or sentences, because the symbols sit far from the home row. Compare code runs only with other code runs.
- Typing practice has a code category with five snippets: a React component, a Python function, a TypeScript interface, an SQL query and a CSS grid layout.
- The typing lessons include a numbers and symbols lesson for the number row and common punctuation.
- The heatmap and weakest-keys list on the progress page show the physical keys, including the bracket, quote and punctuation keys, so you can see which of those you miss. Shifted symbols such as curly braces are not shown as separate keys.
With only five code snippets, you will see repeats. Use them as a warm-up for symbol accuracy, and keep most of your practice in real work.
What not to do
- Do not chase a WPM number for its own sake. No evidence supports a particular target for programmers.
- Do not trade accuracy for speed. See how to improve typing accuracy.
- Do not skip the basics. If you still look at the keyboard, learning to touch type is a one-time investment that makes every later hour easier. Start with touch typing for beginners.
Limits of this guide
- Both studies measured activity by observing computer use, so "editing" is an inferred category and the exact percentages should be read as approximate.
- The first study used a single IDE and a small group of developers. The second covered 79 developers on 7 projects, which is larger but still a limited sample of the industry.
- Neither study measured typing speed, so nothing here tells you how fast programmers type.
Sources
- Minelli R, Mocci A, Lanza M. I Know What You Did Last Summer: An Investigation of How Developers Spend Their Time. IEEE International Conference on Program Comprehension, 2015.
- Xia X, Bao L, Lo D, Xing Z, Hassan AE, Li S. Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering, 2018.
- The 2.5% estimate, the reasons typing still matters and the editor-shortcut hypothesis are our own reasoning. Descriptions of the FreeTyper tools come from the speed test, practice and progress guides.
Written by Ashiqur Rahman. Figures attributed to a source were checked against that source. If you spot something wrong, tell me and I will correct it.