How Many Lines of Code Per Hour Do Developers Write?

Studies of professional software engineers consistently show that the average developer produces 10 to 20 lines of production-ready code per working hour. This number shocks most people outside the industry — and many inside it. The reason the number is so low is that writing code is only one of many activities in a developer's workday. The rest of the time is spent reading existing code, understanding system context, debugging, researching unfamiliar APIs, reviewing other people's work, writing documentation, attending meetings, and thinking through design decisions before writing a single line. The act of physically typing code represents perhaps 20–30% of actual working time.

The 10–20 LOC figure refers to net new production-ready code — lines that were written, reviewed, and merged into the main codebase. It does not include lines that were written and then deleted during exploration, lines in scratch files or test scripts that never made it to production, commented-out code, or whitespace lines. If you counted every keystroke a developer makes in a working day — including experimental code, debug statements, and temporary snippets — the number would be much higher. The distinction matters because 'lines of code' as a productivity metric is notoriously misleading: a developer who writes 5 well-designed lines that replace 100 poorly-designed ones has added more value, not less.

Given that developers spend only a fraction of their day actually typing code, why does typing speed matter at all? The answer is flow state. When you know what you want to write and your fingers can keep up with your thoughts, you stay in the problem-solving mindset. When your fingers lag behind your thoughts — when you have to slow down to find a bracket, or stop to correct a typo — the physical act of typing creates cognitive friction that pulls you out of the problem space and into the mechanical space. Fast, accurate typing does not make you write more code per hour — it makes the code you do write feel effortless. That effortlessness is what developers who have improved their typing speed consistently describe as the benefit.

A large fraction of the text developers type is not code at all. Pull request descriptions, code review comments, documentation, Slack messages, email, Jira tickets, and commit messages together constitute a significant portion of a developer's daily typing. For many developers — especially senior engineers and team leads — non-code writing exceeds code writing in total character count. Typing speed and accuracy on natural language text directly affects the quality and frequency of this communication. Developers who struggle with typing tend to write shorter, less informative PR descriptions and commit messages — a genuine cost to team effectiveness that rarely gets attributed to typing speed.

One place where typing speed has a clear and direct impact on output is refactoring. When you are restructuring code — renaming variables, reorganizing functions, extracting components — you often need to type the same or similar patterns many times in rapid succession. A developer who types quickly can iterate through refactoring options at the speed of thought, testing different names or structures with minimal friction. A developer who types slowly invests significant time in each iteration, which creates a subtle bias against exploring alternatives. The result is that faster typists tend to produce cleaner final code — not because they are smarter, but because the low friction of typing encourages more iteration.

If you want to understand how much your typing speed is affecting your daily output, take a baseline test on CodeSpeedTest in your primary language. Your WPM score tells you how fast you type code when you are purely focused on typing — your theoretical ceiling. The difference between this score and your subjective sense of how fast you code during a real workday reflects all the other factors (thinking, reading, debugging). If your typing WPM is already above 60 and you still feel slow, the bottleneck is probably thinking speed or tooling, not typing. If your typing WPM is below 40, improving it will have a noticeable impact on the code-writing portions of your day.