Keep your eyes on the code, not the keyboard

Code is only part of what you type

The picture of a developer who spends the whole day writing code doesn't match the data. In a 2025 survey of 484 software developers at Microsoft, coding took up about 11% of an actual workweek. Communication and meetings took about 12%, and pull requests and code reviews about 5%. These are self-reported numbers from a single company, not measurements, but the direction is clear: a large share of the job happens outside the editor.

Outside the editor, though, you are still typing. In the 2025 Stack Overflow Developer Survey, 52% of professional developers said they had used Jira regularly over the past year. More than a third regularly used Confluence, and about as many worked in Markdown files. Every one of those tools is full of text someone typed by hand.

Add it up and a normal week looks less like a coding marathon and more like a steady stream of writing, much of it in plain English:

• commit messages and pull request descriptions,
• code review comments and replies,
• tickets, bug reports and estimates,
• documentation, READMEs and design notes,
• Slack or Teams messages and email,
• prompts and follow-ups for an AI assistant.

Developers don't just write code. They write everything that grows up around it.

Typing speed is not your bottleneck

If you expect ten fingers to ship features in half the time, we have to disappoint you. A field study of 78 professional developers across seven real projects recorded 3,148 working hours. On average, about 58% of that time went to program comprehension: reading, navigating and making sense of code. Writing new code was a much smaller slice.

Code is read far more than it is written, and your head sets the pace, not your fingers. Everyday writing works the same way. In a 1999 study by Karat and colleagues, people averaged 33 words per minute when transcribing text and only 19 words per minute when composing their own. Thinking slows you down, and that is fine.

So why train at all? Because typing is not only about speed. It is also about flow. Researchers at Aalto University in Finland noticed that fast typists press each key with the same finger every time, which reduces the need to look at the keyboard and to decide which finger goes where. When your hands handle that on their own, typing stops interrupting the thought you are trying to put into words.

The payoff is smaller than you might hope, but it shows up every day: fewer interruptions, less hunting for characters, and more attention left for what you are actually saying. You feel it most in long stretches of prose, like tickets, documentation and code review.

Touch typing won't make you a better programmer. It removes a little friction from every line you write.

Where your eyes go while you type

At Aalto University, researchers recorded 30 people typing with motion capture cameras and eye-tracking glasses. Touch typists looked at the keyboard about 20% of the time. Self-taught typists looked down about 41% of the time, roughly twice as much, even though the two groups typed at similar speeds. The authors concluded that touch typing is not necessarily faster, but it lets you keep your visual attention on the display.

The study did not look at programming specifically, although the authors noted that keyboards are now used for many tasks, including gaming and programming. In an editor, a lot happens on screen while you type: autocomplete suggests a name, a linter underlines a mistake, a closing bracket appears, or an AI assistant offers a completion. If your eyes are on your hands, you miss it.

Eyes on the screen also mean you catch a typo the moment it happens. In a large online study of 168,000 volunteers, the most common error was swapping one character for another, and about 1.2% of characters in the submitted text were still wrong. Your compiler will often flag a misspelled variable. A typo in a string, a comment, a config key or a commit message usually slips through without a warning.

To be fair, the smaller Aalto study did not find that touch typists made fewer errors than self-taught typists. The advantage is noticing mistakes sooner, not avoiding them altogether. That is why Touchtypely shows your accuracy, error rate, corrected and uncorrected errors, and your most frequent key mix-ups after every exercise.

A typo you see right away takes a second to fix. A typo in a commit message stays in the history.

Brackets and symbols on a US keyboard

Code is packed with characters you rarely use in everyday writing: curly and square brackets, semicolons, equals signs, slashes, pipes and at signs. On a standard US QWERTY keyboard, the good news is that none of them need special modifier keys. Some have a key of their own, the rest sit on the same key with Shift.

The catch is location. Many of these keys live on the far right of the keyboard, and most of them belong to your right pinky, the weakest finger you have. If they are not in your fingers yet, your eyes drop to the keyboard every time you open a block or end a line. In code, you press them over and over.

Module 6 of the Touchtypely course covers numbers and symbols: the digit row, punctuation, @, $ and the numeric keypad. The keypad lesson is optional, so skip it if your laptop doesn't have one. If only a few keys slow you down, you can pick specific keys to drill, and after every exercise you see which keys are your slowest. A quick map of the US layout:

• [ ] square brackets: their own keys, right of P, typed with the right pinky,
• { } curly braces: Shift + [ and Shift + ],
• ( ) parentheses: Shift + 9 and Shift + 0,
• ; semicolon: its own key on the home row, under the right pinky, and : is Shift + ;,
• = equals: right of the hyphen key in the number row, and + is Shift + =,
• / slash: its own key in the bottom row, and ? is Shift + /,
• \ backslash: right of the ] key, and | pipe is Shift + \,
• < > less than and greater than: Shift + comma and Shift + period,
• @ at sign: Shift + 2, and ~ tilde is Shift + ` (the key left of 1).

A curly brace should feel as natural as the letter a.

Editor shortcuts under your fingers

The Vim user manual explains why the cursor moves with h, j, k and l. Moving the cursor is the most common thing you do in an editor, and those keys sit on the home row of your right hand, where, as the manual puts it, you can type them fastest, especially when you type with ten fingers. Reaching for the arrow keys means leaving the letters, and repeated often, that adds up. In the 2025 Stack Overflow survey, 24% of respondents said they used Vim regularly and 14% used Neovim.

You don't need Vim to feel the difference. Visual Studio Code, used regularly by about three quarters of the same survey's respondents, opens a file with Ctrl + P, the Command Palette with Ctrl + Shift + P, and adds the next match to your selection with Ctrl + D. Toggling a line comment is Ctrl + /. On a Mac, swap Ctrl for Cmd. With your hands resting on the home row, you can press all of these without looking.

Touchtypely does not train editor shortcuts directly. What it does teach is where every key lives and which finger owns it. Once you know that for letters, digits and punctuation, shortcuts stop being a hunt and become a reflex.

A hand that never leaves the home row never has to find its way back.

When AI writes some of the code

More than 49,000 people from 177 countries answered the 2025 Stack Overflow Developer Survey. 84% of respondents use or plan to use AI tools in their development process, and about half of professional developers use them every day. It would be easy to conclude that typing no longer matters.

The same survey shows the other side. 46% of respondents distrust the accuracy of AI output, while 33% trust it. The most common frustration, cited by 66% of developers, is AI solutions that are almost right, but not quite, and 45% say debugging AI-generated code takes more time. Suggestions still have to be read, understood and often fixed by hand.

Working with AI also changes what you type rather than simply reducing it. A good prompt with context, constraints and examples is a paragraph of clear prose. You spend more time reading and reviewing, which is where eyes on the screen help, and more time explaining what you want in plain English, which is where fluent typing helps.

With AI you type less code, but you read more and describe more.

Long hours at the desk

For computer work, the Occupational Safety and Health Administration recommends a head that is level, forward facing and generally in line with your torso, relaxed shoulders, elbows close to your body, and hands, wrists and forearms straight and roughly parallel to the floor. OSHA suggests placing the top of the monitor at or slightly below eye level, about 20 to 40 inches from your eyes. If you keep glancing down at your hands, you keep leaving that position.

If you code on a laptop all day, the screen usually sits far below eye level. A separate keyboard and a stand that raises the laptop screen are worth considering, and they make touch typing even more useful, because the keyboard is no longer right under your nose.

The World Health Organization advises all age groups to limit the time they spend sitting and reminds us that any amount of physical activity is better than none. For adults, the WHO links more sedentary time with higher rates of heart disease, cancer and type 2 diabetes. A short walk after a long block of code is not laziness.

We did not find a study that directly compares neck pain in touch typists and in people who look at their keys, so we won't promise you a healthier back. A typing course won't get you out of your chair. It can help you stop tilting your head down toward your hands.

Monitor at eye level, eyes on the monitor, and stand up now and then.

What about Dvorak or Colemak?

Some developers switch to alternative layouts such as Dvorak or Colemak, or build custom layouts on programmable keyboards. That is a legitimate choice, and people who make it usually have strong opinions about it. It also comes with a cost: shortcuts move, shared and borrowed machines feel foreign, and it takes weeks before you are back to your old speed.

Touchtypely teaches the standard US QWERTY layout on Windows and Mac, in a current browser with a physical keyboard. It does not teach Dvorak, Colemak or custom layouts. If you are already happy on one of those, this course is not for you.

Our honest advice: if you mostly use QWERTY and you look down at the keyboard, learning proper touch typing on QWERTY gives you the biggest gain for the least disruption. You keep every default shortcut, every laptop works the same way, and pair programming on a colleague's machine stays painless.

The best layout is the one you can type on without looking.

How to train alongside your job

The course has 26 lessons in 6 modules, plus a final exam. A lesson takes 5 to 8 minutes, so the whole course is about 2 to 3.5 hours of practice, or about a month at one lesson a day. A colored on-screen keyboard and hands show you the next key and the finger to press it with. When you pass the final exam, you get a certificate with a public verification link. It is not an official credential, just a record of your result that anyone can check.

If you already type quickly in your own style, the first few days will feel slower, and you will be tempted to go back. A 2003 study by Yechiam and colleagues describes exactly this: success in a touch typing course does not guarantee that people keep using it in everyday work, partly because looking at the keys gives a better result right now. In their experiment, it helped when the task rewarded keeping your eyes on the screen. Touchtypely shows the keyboard and hands on screen, so you look up for the next key, not down. Start in a calm week, not the week before a release.

After the course, a daily training session of 5, 10, 15 or 20 minutes is built automatically from your weak keys, keys that are starting to slip, and a practice text from a genre you choose. You can also pick specific keys to drill on their own.

To track progress, take a typing test of 30 seconds, 1, 3 or 5 minutes and compare yourself on the leaderboard if you want to. After every exercise you see WPM, accuracy, error rate, rhythm and your reaction time per key. Short daily sessions also have research behind them: in a classic 1978 study, British postal workers learned to type most efficiently with one hour a day rather than longer, more concentrated blocks.

Five minutes every day beats an hour once a month.