Typing Code vs Prose: Why Your WPM Collapses in an Editor

A typing test tells you how fast you move English through your hands. It does not tell you how fast you write code, and the gap between those two numbers is larger than almost anyone expects. Typists who comfortably hold 90 words per minute on prose routinely describe collapsing to something that feels like half that inside an editor, and the usual explanations offered are unsatisfying: that thinking gets in the way, or that code is just harder.

Both of those are partly true and neither is measurable. So instead of guessing, I measured the material. This site is a production Next.js application with a large body of published writing sitting in the same repository, which makes it an unusually convenient natural experiment: real source code and real professional prose, written by the same hands, in the same project, available as plain text. Material turns out to decide a great deal — it is also the reason the typed-versus-handwritten notes question keeps producing null results, why dispatchers drill addresses and surnames rather than prose, and why support agents should practise order numbers rather than paragraphs.

The result is not that code is a bit harder to type. It is that code is a different character distribution wearing the same keyboard, and the specific way it differs lands almost entirely on the keys that typing practice never covers.

What I measured, and what came out

The code corpus is every TypeScript and TSX file in this project's source directory, excluding three files that are ninety-five percent English prose held inside string literals — including those would have measured prose and labelled it code. That leaves 71 files and 372,441 characters of genuine application source: components, hooks, route handlers, schema builders, statistics functions.

The prose corpus is the published body text of the articles on this blog, extracted from the same repository and normalized so that typographic punctuation is counted as the ASCII key a typist would actually press. Curly quotes become straight quotes, em dashes become hyphens. Without that step the comparison would flatter prose by pushing its punctuation outside the character classes being counted. That gives 335,433 characters of edited professional English.

One methodological decision is worth stating plainly, because it changes the headline number. Raw source files are 26.3 percent spaces, most of which is leading indentation. Nobody types indentation space by space — editors insert it — so counting it credits code with keystrokes that are never made. I report both views throughout: the raw file view, and the view with leading indentation stripped, which is closer to what a person actually presses. The shifted-character share is also why symbol-heavy work is hardest for anyone typing one-handed without Sticky Keys.

Read the bottom two rows together, because they are the whole article. Prose is a stream of lowercase letters interrupted by an occasional comma. Code is a stream of lowercase letters interrupted constantly by characters that need a modifier, a reach to the top row, or both.

Symbols: one character in six, against one in fifty

The single most useful way to hold this in your head is as a frequency. In prose, a symbol arrives roughly every fiftieth character — that is a period, a comma, an apostrophe, occasionally a hyphen. In code, once indentation is set aside, a symbol arrives roughly every sixth character.

That is not a small increase in difficulty. It is a change in what the task is. A prose typist spends the overwhelming majority of their keystrokes inside a well-rehearsed motor vocabulary of lowercase letters and spaces, and the punctuation is rare enough that even a slow, deliberate reach for it costs almost nothing across a page. In code the punctuation is not an interruption to the flow; it substantially is the flow.

Look at the right-hand column of that chart. Of the eight most frequent symbols in this codebase, five require Shift and six sit under the right hand, most of them on the pinky. That is not a coincidence of one project's style — it follows from the shape of the QWERTY layout, which put the entire punctuation cluster on the right edge in an era when the material being typed was letters, and from the design of C-family syntax, which drew its delimiters from that same cluster.

The Shift tax nobody accounts for

Shift is the most underrated cost in this whole comparison, because it does not appear in any keystroke count. A capital letter is one character on screen and two keys under the hands. So is every brace, colon, underscore, plus sign and angle bracket.

In prose, 1.2 percent of characters need Shift, which is essentially the capital letter at the start of each sentence and the occasional proper noun. In code the figure is 12.5 percent. One keystroke in eight is a two-key combination requiring a coordinated press-and-hold with the opposite hand — assuming, that is, that you use the opposite hand, which many self-taught typists do not.

Eleven percent of extra physical presses is real but it is nowhere near the size of the slowdown people report, which tells you something important: the Shift count is not the mechanism. The mechanism is that the shifted characters in code are drawn from the small set of keys that ordinary practice never automates, so each one is a small conscious act rather than a rehearsed movement.

This is also where a specific and very common habit becomes expensive. Pressing Shift with the same hand as the target key forces a contortion that pulls the hand off its home columns, and in prose you pay that cost once a sentence. In code you pay it every eighth character. It is the single highest-leverage fix available to a developer who types by feel, and it is covered as a habit in the mistakes that quietly cap your speed.

Where the load lands: the right pinky

Distribute those symbols across the hand and an uncomfortable picture appears. Characters owned by the right pinky — P, semicolon, colon, quote, slash, question mark, the four bracket keys, backslash, pipe, hyphen, underscore, equals and plus — account for 2.4 percent of prose characters and 10.9 percent of code characters.

The right pinky is the weakest and least independent finger on the hand. It is also, on a standard staggered keyboard, the one making the longest reaches. In prose that barely matters because its workload is small. In code it is carrying roughly one keystroke in nine, and doing it while frequently also holding Shift.

The left pinky, interestingly, goes the other way: 6.7 percent in prose against 4.7 percent in code, because its main job in English is the letter A, and code has proportionally fewer letters. So the two weakest fingers swap roles entirely between the two materials, which is a neat illustration of why fluency in one does not imply fluency in the other. If you have never explicitly worked on the right-hand column, the full finger map is the place to start, because no amount of symbol drilling helps if the underlying assignments are wrong.

Whether this concentrated loading is bad for your hands over years is a question I want to be careful about. The mechanism is plausible and it is the kind of pattern ergonomics research attends to, but I have not seen it measured for programmers specifically, and the general evidence linking keyboard work to nerve injury is weaker than most people assume — which is set out in what the research on typing and carpal tunnel actually shows. Treat discomfort as a reason to change your setup, not as proof of damage.

The number row you never drilled

Digits are 0.28 percent of prose and 2.2 percent of code, an eightfold difference. In absolute terms 2.2 percent still sounds small, and that is exactly why it goes unaddressed: it is frequent enough to interrupt you regularly and rare enough that you never decide to fix it.

The number row is the worst-served part of the keyboard in every typing curriculum. It is furthest from home position, it requires the full stretch of each finger, and it is almost entirely absent from prose practice material. Most competent typists — including fast ones — are effectively hunt-and-peck above the top letter row, and they discover this the first time they type a port number, a version string, an array index or a hex color.

There are two separate skills hiding here, and conflating them wastes practice time. Typing scattered digits inline within code is a number-row skill. Entering long runs of digits is a keypad skill, which is a genuinely different technique with its own home position, covered in learning the numeric keypad properly. Developers overwhelmingly need the first. If you find yourself reaching for the keypad to type a single array index, you have substituted one problem for another.

Why word chunking does not transfer to code

Here is the deeper reason a fast prose typist is not automatically a fast code typist, and it has nothing to do with symbol counts.

Fast typing is not fast individual keystrokes. It is chunking: common letter sequences execute as single motor gestures rather than as sequences of separate decisions. The reason this works in English is that English has a stable, steep frequency distribution — the same handful of bigrams and trigrams recur constantly. Peter Norvig's analysis of the Google Books corpus letter and bigram frequencies puts TH, HE, IN, ER and AN at the top of a distribution that any English typist has rehearsed millions of times without trying.

The large-scale typing research points the same way. The Aalto study of 136 million keystrokes from 168,000 typists found that performance was predicted less by raw finger speed than by rollover — beginning the next keypress before releasing the previous one — which is precisely what chunked, overlapping motor sequences look like. The full CHI 2018 paper is worth reading if you want the methodology.

Code has chunks too. The arrow, the closing paren-brace-semicolon run, the JSX closing tag — these are real recurring sequences and experienced developers absolutely do execute them as single gestures. But you can only have built those chunks by writing a lot of code in that specific language. They do not arrive from prose practice, and they do not transfer cleanly between languages either, which is why a fluent TypeScript developer feels clumsy in a Lisp for reasons that have nothing to do with understanding it. The same specificity is why thousands of hours of gaming build no typing speed despite obvious keyboard fluency.

This is the specificity of practice principle, which is well established in motor learning research: training effects are strongly task-specific, and transfer between related motor sequences is partial at best. It is the same mechanism that explains why phone fluency does not transfer to a keyboard, and why plateau-breaking requires changing what you practice rather than doing more of it — a point developed in why typing speed stops improving.

camelCase, snake_case and the mid-word Shift

Identifier conventions deserve their own section because they do something no English word does: they put a capital letter or an underscore in the middle of a token.

In prose, capitalization is positionally predictable. It happens at the start of a sentence or the start of a name, which means the Shift press is prepared during the pause that precedes it. camelCase puts the Shift press inside a continuous motor sequence, at a position that varies from identifier to identifier. That is a genuinely different motor demand: not more keystrokes, but a modifier press that has to be scheduled mid-flight.

snake_case trades that for a different cost. The underscore is Shift plus a right-pinky reach to the top row, which is one of the most awkward single characters on the board, and it appears at every word boundary rather than once per sentence.

There is a research literature comparing these conventions, though it is about reading rather than typing. Binkley and colleagues ran an eye-tracking study on camelCase and under_score identifier styles and found no accuracy difference, but faster recognition for underscores among programmers trained on them — a result that reversed an earlier study whose subjects were trained the other way. The honest summary is that training dominates the convention, which is roughly what you would expect and is a useful corrective to strong opinions in either direction.

For typing specifically, no such study exists as far as I can find. What the character measurement can say is narrower and still useful: both conventions add a modifier press per word boundary that English does not have, and the underscore version puts that press on the weakest finger.

Brackets, quotes and the auto-close problem

Openers — the parenthesis, bracket, brace, and the three quote characters — are 3.5 percent of the code corpus. Every one of them is half of a pair, and this creates a problem that does not exist anywhere in prose typing.

Every modern editor auto-closes them. You type the opener and the closer appears. This is genuinely useful and it also quietly breaks the feedback loop that builds typing automaticity, because the closing character is now sometimes typed and sometimes typed-over. Most editors are smart enough that typing the closer when one is already there just moves the cursor past it, which means both behaviors produce correct output and neither is ever corrected.

The result is a motor pattern that stays permanently semi-conscious. You are never quite sure whether you need to type the closing brace, so you glance. That glance is the same interruption that hunting for a key causes, and it is invisible in any keystroke count because the output is always right. It is a small, specific example of a general principle: automaticity requires consistent feedback, and tooling that silently accepts two different inputs removes it.

I am not suggesting you disable auto-close. The productivity case for it is obvious. I am suggesting that if you have ever wondered why bracket typing never feels as automatic as letter typing after years of practice, this is a large part of the answer, and the fix is to pick one behavior deliberately and always do that.

What a typing test can and cannot predict about coding

Given all of the above, what does a standard typing score actually tell a developer?

It measures the letter layer accurately, and the letter layer is roughly two thirds of code characters. That is not nothing. If your prose speed is below about 45 words per minute you are almost certainly still locating keys visually, and that ceiling will follow you into an editor unchanged — the fix there is method rather than practice, and it is the same fix as for prose. Where your prose number sits against everyone else is laid out in the average typing speed distribution.

What it cannot see is the symbol layer, because standard test passages contain almost none of it. This is the same structural problem that makes scores differ between typing sites at all: passage composition is one of the main reasons the same typist gets different numbers in different places, which is worked through in why your WPM differs between typing tests. A test built from common English words is measuring your best-rehearsed material by construction.

So use a prose score as a floor and a diagnostic, not as a prediction. If you want a number that means something for code, the only honest way to get one is to type code and time it. You can take a timed prose run at three minutes or longer to establish the baseline, then compare it against a code sample of your own.

The realistic ceiling for typing code

It is worth saying clearly that the goal here is not a high code words-per-minute figure, because that figure is close to meaningless. Very little of a working day is continuous code transcription. The Stack Overflow developer survey consistently shows most developers in editors all day, but time-in-editor is dominated by reading, navigating and editing rather than by originating characters.

That is the same argument that applies to typing speed generally past a certain threshold, and it is developed at length in where typing speed genuinely stops mattering. The diminishing return is real and it arrives early.

The case for working on this is not throughput. It is attention. When a brace requires a small conscious act, that act is taken directly from the part of your mind that was holding the problem. Nobody notices the two hundred milliseconds; everybody notices having lost the thread. The value of automating the symbol layer is that it stops interrupting the thinking, and that is a qualitatively different benefit from typing more characters per minute.

What autocomplete and AI assistants change

The obvious objection to all of this is that modern tooling types most of the characters for you. It is a fair objection and the answer is more interesting than either side usually allows.

Completion is not new and it is heavily used. An empirical study of how developers actually use code completion found it among the most frequently invoked commands in the editor, comparable to copy and paste. What completion removes is bulk identifier typing — the long camelCase names — which is precisely the letter-dominated part you were already fastest at. What it removes least reliably is the punctuation scaffolding around them.

Generative assistants change the shape more aggressively, and the evidence on whether they make developers faster is genuinely mixed rather than settled. A controlled trial of GitHub Copilot on a JavaScript task reported completion around 56 percent faster. A later randomized trial from METR found that experienced open-source developers were 19 percent slower with AI tools on mature repositories they knew well — while believing they had been 20 percent faster. The full METR paper is worth reading before drawing conclusions in either direction.

The pattern worth extracting is that all of these tools substitute reading and judging for typing. That trade is often good and it is never free, because a suggestion has to be evaluated even when accepting it costs one keystroke. This is the same structural argument that applies to text expansion and shortcuts generally, examined in the case for typing fewer keystrokes rather than faster ones.

Should you switch to a programmer keyboard layout?

There is a layout designed around exactly the finding on this page, and it deserves credit for getting there first. Programmer Dvorak moves the digits into the shifted positions and puts the symbols on the unshifted number row. Its author states the reasoning directly: symbols are used much more in code than numbers are, and the layout was verified by scanning thousands of lines of source across several languages. Independent write-ups such as the case for the Programmer Dvorak layout cover what living with it is like.

That is a genuinely correct diagnosis. My measurement, arrived at independently on a different codebase in a different language, agrees with its premise: symbols outnumber digits in source code by roughly eight to one.

The prescription is the part I would be cautious about. Switching layouts costs six to eight weeks below your working speed, the general evidence that alternative layouts produce a speed gain is weak, and every shortcut in every tool you use is bound to QWERTY positions. The full arithmetic on layout switching, including why the payback rarely arrives, is in the honest math on Dvorak, Colemak and mechanical keyboards. Treat Programmer Dvorak as a well-argued diagnosis of the problem rather than as a recommendation to act on.

The keys worth remapping before anything else

If you do not want to relearn a layout, there is a much cheaper intervention that addresses the actual finding. Caps Lock occupies the best-positioned key on the keyboard and performs a function almost nobody wants. Remapping it — to Escape, to Control, or to a modifier layer that puts brackets under the home row — converts dead real estate into the most valuable position on the board.

The tooling is unremarkable and free. Windows ships PowerToys Keyboard Manager for simple remaps, AutoHotkey handles arbitrarily complex ones, and editors themselves expose full keybinding customization. Why that key is there at all, and what else on your keyboard is similarly vestigial, is the subject of the keys nobody uses.

For characters that are not on the keyboard at all — arrows, typographic dashes, accented letters in string literals — the compose key and dead key mechanisms are worth knowing, and the practical methods per platform are collected in how to type special characters.

A practice plan that actually transfers

Everything above points to one conclusion about practice: general typing practice will not fix a symbol problem, because general typing practice does not contain symbols. The material has to match the target.

The reason for working below your maximum is not caution, it is mechanism: rhythm degrades the instant you strain, and practicing at full speed rehearses the errors that come with straining. The general structure of a session that produces change rather than volume is set out in a practice routine that actually moves the number.

How to test yourself honestly

Measuring your own progress here requires a little care, because the obvious method is biased. Retyping a file you have retyped before measures your memory of it as much as your typing, in exactly the way that fixed-quote typing tests do.

Use a file you have not practiced on for the measurement, keep the practice files separate, and take the measurement on a comparable day. Day-to-day variation in typing speed is larger than most people credit — often enough to swamp a real week of improvement — which is worth accounting for before concluding anything, and is covered in why the same typist scores differently from one day to the next.

Track accuracy separately and weight it heavily. A syntax error costs far more than the keystrokes it took to make, because it interrupts you at the point where you were holding context. The relationship between raw speed, net speed and error rate, and why the gap between them is the most diagnostic figure on a results screen, is explained in what WPM, accuracy and consistency actually measure.

If you want the mechanics of the test interface itself — durations, the per-second graph, the character review — the site tutorial documents all of it. And if you are evaluating practice tools rather than building your own drills, the comparison of typing programs covers which ones teach and which merely occupy time. None of them, it is worth noting, drills symbols seriously.

What none of this means

Some limits on the measurement, stated plainly, because a number presented without its caveats is worth less than no number.

This is one codebase, in one language family, written by one person. TypeScript with JSX is unusually punctuation-dense — angle brackets and braces appear in the markup layer as well as the language layer — so a Python codebase would very likely show a lower symbol share, and a Lisp a higher one. The direction of the finding is robust and the exact ratio is not. I would expect any C-family language to land in the same broad territory and would not be surprised by a meaningful spread.

The prose corpus is also a specific kind of English: edited explanatory writing, which is comparatively light on quotation marks and parentheses. Fiction with dialogue would score higher on punctuation than these articles do. That would narrow the gap somewhat. It would not come close to closing it, because nothing in English prose approaches one symbol in six.

And the character analysis says nothing directly about speed. It measures the material, not the typist. The link from symbol density to slower typing runs through the chunking argument, which is well supported in general and which I have not tested on code specifically. That would take a controlled study with real developers, which is a genuinely worthwhile thing for somebody to run.

What I am confident about is narrower and still useful. The material you type when you write code is a substantially different distribution from the material every typing test measures, the difference is concentrated on the keys that practice never covers, and the gap between your prose score and your code fluency is not a mystery about thinking. It is a training gap, and it responds to training that matches the material.

That is a more encouraging conclusion than the usual one. Feeling slow in an editor after years of fast typing is not evidence that you have hit a limit. It is evidence that you have been practicing something else.