Typing for developers: symbols, brackets and code

Why your prose speed does not carry over

Many developers are surprised that their typing test score says little about how fast they write code. The reason is the characters. Prose is mostly lowercase letters and spaces, typed from the home row in familiar word patterns. Code is full of brackets, operators, quotes, digits, capitals in the middle of words and punctuation that ordinary text barely uses.

Those characters live on the edges of the keyboard: the number row, the corners under the little fingers and keys that need Shift or a modifier. Your fingers travel further, the patterns are less familiar and every Shift is an extra coordinated movement. Someone who is fluent on words can still hesitate on a line like an arrow function with a default parameter, because they have simply typed those combinations far less often.

Code also asks more of your reading. You are tracking structure, names and nesting while you type, so speed is limited by thinking as much as by fingers. That is fine: the goal is not to type code at prose speed, but to stop symbols from interrupting your thought.

Where the time actually goes

Watch yourself write a few lines of real code and you will usually find the same spots slowing you down.

• Reaching for brackets and braces, especially when they need Shift or AltGr.
• Glancing down to find a symbol on the number row.
• Holding Shift with the same hand that has to press the key.
• Mixed-case names such as camelCase identifiers, where Shift lands in the middle of a word.
• Fixing a typo in a long name, which costs more than the typo itself because you have to find it first.

Learn the symbols properly

Treat each symbol like a letter you have not learned yet. Decide which finger presses it, and use the Shift key on the opposite hand from the key you are pressing. Using both Shift keys feels awkward for a while, but it keeps both hands in position and removes a stretch that slows down every capital and every symbol.

On Turkish Q and F layouts, and on several other European layouts, characters such as curly braces, square brackets, the at sign, the hash, the backslash and the vertical bar are typed with AltGr. That is a three-part movement and worth drilling on its own until it stops being a pause. Some developers switch to an English layout for coding for exactly this reason; others prefer to keep one layout for everything. Both are reasonable, but switching back and forth costs some accuracy at first.

Brackets, pairs and your editor

Most editors close brackets and quotes for you, indent new lines and complete names. That changes what is worth practising. Typing a long identifier perfectly matters less when completion finishes it; typing the opening of a structure quickly and accurately matters more.

Know how your editor behaves and practise with it, not against it. If it inserts the closing bracket, learn to type through it rather than deleting it. If it indents for you, do not fight it with extra spaces. Smooth code typing is as much about trusting your tools as about raw finger speed.

Indentation and new lines

In code, a line break is part of the text, not just a place where the line wraps. The code mode on the home page treats it that way: Enter types a new line, and after a correct Enter the indentation on the next line is skipped automatically, much as an editor would indent it for you. Those automatic spaces are not counted as your keystrokes, so they do not inflate your speed.

Tab does not insert indentation in code mode. While you are typing it is ignored, so an indentation reflex does not wreck the run; before you start typing, Tab gives you a different snippet.

Practising code on the home page

Open the practice group in the bar above the warm-up test and choose Code. You get a real-looking snippet from a pool covering fourteen languages: JavaScript, TypeScript, Python, Java, C#, Go, Rust, PHP, SQL, HTML, CSS, JSON, Regex and Shell. On the home page the language is mixed, and the result shows which language the snippet was in. The whole snippet is visible and the run ends when you finish it, so you are measured on the full piece, not on a time window.

Custom mode, in the same group, lets you paste your own text of 20 to 5000 characters. Line breaks and repeated spaces are flattened into single spaces, so it suits drilling a tricky expression or a list of identifiers from your own project rather than a whole indented file.

Punctuation and numbers for the basics

The warm-up test has two switches, punctuation and numbers, that work in both time and words mode. Punctuation turns the word stream into short sentences with a capital letter at the start, a full stop, question mark or exclamation mark at the end and the occasional comma. Numbers turns roughly one word in seven into a number of one to four digits.

Neither switch adds brackets or operators, so they are not code practice in themselves. They are a good bridge: capitals train your Shift timing and numbers train the top row, which are exactly the movements code leans on. Runs with these switches on count as free practice, so they do not affect leaderboards or the league.

A simple routine for developers

A few minutes a day works better than one long session a week.

• Start with a short warm-up in time mode to settle your hands.
• Do one or two runs with numbers on, then with punctuation on, focusing on clean Shift use.
• Finish with a few code snippets, aiming for zero mistakes rather than speed.
• Once a week, paste a line or two from your own code into custom mode and drill the patterns you use most.

Accuracy is worth more in code

In prose, a typo is a small blemish. In code it is a bug, a failed build or a confusing error message, and finding it can take far longer than typing the line did. Clean, steady typing beats bursts of speed followed by hunting for mistakes.

So measure progress by how often you get through a snippet without errors, not by your fastest run. Speed will follow once the symbols stop being obstacles.