What's a Good Typing Speed for Programmers? WPM Benchmarks by Level
The short answer: a good typing speed for programmers is 50-70 WPM on plain text and 30-45 WPM on actual code. If those two numbers look far apart, that gap is the whole point of this article - and almost every typing benchmark you have seen measures the wrong one.
1. How WPM Is Actually Measured
Before any benchmark means anything, you need to know what a "word" is. In typing measurement, a word is not a word at all - it is a fixed unit of five characters, including spaces and punctuation. This standard exists so that "antidisestablishmentarianism" and "cat" do not distort the score.
The formula
WPM = (characters typed / 5) / minutes elapsed
There are two versions of this number, and the difference matters more for developers than for anyone else:
-
•
Gross WPM
Everything you typed, mistakes included. This is the flattering number.
-
•
Net WPM
Gross WPM with errors subtracted. This is the number that reflects real output.
When a typing site tells you that you hit 80 WPM, it is almost always reporting your speed on ordinary English sentences: common words, predictable letter pairs, and virtually no symbols. That number tells you something real about your hands. It tells you very little about how fast you can write a function.
2. Typing Speed Benchmarks by Experience Level
Here is a realistic ladder. The prose column is what a standard typing test would show you. The code column is what you should expect when the same hands are typing brackets, operators, and identifiers instead of English.
Beginner - under 30 WPM prose / under 20 WPM code
You are still looking at the keyboard. Speed is not the goal yet; learning to keep your eyes on the screen is.
Average adult - around 40 WPM prose / 20-25 WPM code
This is roughly where the general population sits. Plenty of working developers are here and never measured it.
Competent developer - 50-70 WPM prose / 30-45 WPM code
Touch typing is solid. Your hands are no longer the bottleneck in day-to-day work. This is the target for most people reading this.
Fast developer - 80-100 WPM prose / 50-65 WPM code
Symbols are automatic. You type full expressions without conscious thought about key positions.
Exceptional - 100+ WPM prose / 70+ WPM code
Rare, and well past the point of diminishing returns for most engineering work.
The rule of thumb
Expect your code speed to land somewhere around 55-70% of your prose speed. If you type 80 WPM in English, roughly 45-55 WPM on code is normal. A much wider gap than that usually points at one specific weakness - nearly always the symbol keys.
3. Why Code Is Slower to Type Than English
The gap is not a personal failing. It is structural, and it comes from four things at once.
Symbol density
English is almost entirely home-row-friendly letters. Code is full of characters that live on the number row, the far right of the board, or behind a modifier key. Typing a single arrow function means reaching for parentheses, an equals sign, a greater-than sign, and braces - most of them requiring Shift.
Non-dictionary words
Fast typing relies on chunking: your hands learn whole words as single motions. Identifiers like getUserPreferences or MAX_RETRY_COUNT are not words your muscle memory has ever seen, so you fall back to typing letter by letter.
Case switching
camelCase, PascalCase, and SCREAMING_SNAKE_CASE all demand mid-word Shift presses. English asks for a capital letter roughly once per sentence. Code asks several times per line.
Thinking while typing
You are rarely transcribing code the way you transcribe a sentence. You are composing it. Some of what looks like slow typing is actually design happening in real time - and that part is not a problem to solve.
This is exactly why a generic typing tutor plateaus for developers. It trains you on the character set you are already fast at, and never touches the one that slows you down. Practising on real code in the language you actually work in is what closes the gap.
4. Why Accuracy Beats Raw Speed
In prose, a typo is cosmetic. You fix it later, or you do not, and the sentence still reads. In code, a single wrong character is a syntax error - and the cost is never just the keystroke.
What a typo actually costs you
-
•
The keystrokes to notice, delete, and retype it
-
•
A red squiggle or failed build pulling your attention away from the problem
-
•
The reload of whatever you were holding in working memory before the interruption
That last one is the expensive part. A mistyped bracket at 90 WPM can easily cost more total time than the twenty seconds you saved by typing fast in the first place.
Aim for 97% accuracy or better before you chase a higher WPM. A developer typing 45 WPM at 99% accuracy out-produces one typing 65 WPM at 90% - the second one is spending their day in the backspace key.
5. How to Find Your Real Baseline
Benchmarks are only useful once you know where you actually stand. Measuring properly takes about ten minutes.
Measure both numbers
Take a standard prose test, then a code exercise in your primary language. The difference between them is your real diagnostic.
Use your daily language
Rust and C++ are punishing in ways Python is not. A baseline in a language you never write tells you nothing useful.
Run three attempts, take the median
A single run is noise. Fatigue, an unfamiliar snippet, or one bad line will swing it by ten WPM.
Record accuracy alongside speed
A WPM figure with no accuracy attached is not a measurement, it is a guess.
You can do the code half of this on TurboType's practice exercises, which report WPM, accuracy, and error count on every run and keep your best scores per language so the comparison stays honest over time.
6. How Long Improvement Actually Takes
Typing speed responds to practice, but not linearly, and not quickly. Realistic expectations from 15-20 minutes of focused daily practice:
Speed often drops before it rises. You are unlearning bad habits, which feels like getting worse.
Symbol reaches start becoming automatic. This is where most measurable improvement happens.
Progress flattens. Gains come from specific weak characters, not general practice.
Moving from 30 to 50 WPM on code is very achievable in a couple of months. Moving from 60 to 80 can take a year, and for most developers the effort is better spent on keyboard shortcuts and editor fluency, which have no ceiling in the same way.
7. Common Mistakes to Avoid
Benchmarking yourself on prose only
Your 85 WPM on a generic typing site is not your coding speed, and improving it further will not make you faster at work.
Chasing WPM at the cost of accuracy
Speed built on a shaky error rate collapses the moment you type something that matters.
Practising in one language forever
Each language has its own symbol profile. Comfort in Python does not transfer cleanly to Rust or C++.
Ignoring which characters actually slow you down
Most people lose the same handful of keystrokes over and over. Find yours and drill those specifically rather than practising generally.
Conclusion
A good typing speed for a programmer is 50-70 WPM on prose and 30-45 WPM on code, at 97% accuracy or better. But the number that matters is not where you sit against a benchmark - it is the gap between your prose speed and your code speed. That gap is made of symbols, case switching, and unfamiliar identifiers, and it is the only part of typing that focused practice can meaningfully fix.
Measure both. Work on the difference. And once your hands stop being the bottleneck, stop optimising typing and go optimise something else.
Next Steps:
- Take a standard prose typing test and note the result
- Run three code typing exercises in your main language and take the median
- Calculate your ratio - if code speed is under 55% of prose speed, symbols are your bottleneck
- Practise 15 minutes a day for two weeks, holding accuracy above 97%, then measure again