Is Typing Speed A Factor In Programmer Productivity ?

(1) There's something important you can tell about a person's relationship to computers just by watching them type. The terrible typists were also the worst programmers. How can I take you seriously if you aren't comfortable at the keyboard? I can't believe that somebody who loves to code hasn't spent enough hours at a computer to figure out how where all the keys are, even if they aren't touch typists. Several observations: (a) staring down at the keyboard instead of having eyes on screen results in typos missed until several characters later, requiring extra navigation time, or simply missed until the compiler yells at you, if you've even got a compiler to save you; (b) programming makes use of a lot of symbolic characters, so people who can't even find alphabetic characters on the keyboard are even worse writing code. The most frustrating typist I encountered would occasionally hold down enter instead of shift for several seconds while hunting for '(', only to look up several seconds later and notice they had inserted a huge amount of blank space in the file, followed by a '9'. Did not hire.

(2) Once above a certain minimal threshold of typing competence, there didn't seem to be much correlation between typing skill and programming skill. The person we ended up hiring was also (gently) asked to take an online typing course. Their speed quickly increased from a two-finger 30 wpm to full touch-typing 60 wpm. A noticeable increase in productivity was also observable just by watching them type, especially as typo corrections happened quickly with eyes focused on the insertion point and not on the keyboard. Once you have in mind the code you want to write, then your fingers and text editor can either get out of the way or be a limiting factor.

From a cognitive standpoint: if you're a great programmer but a horrible typist, then how can you not want to increase the data transfer bandwidth between your mind and the editor?

Likewise, playing blitz chess is about making fast decision. How fast you type has no (significant) bearing on how long you spend thinking while you're coding.

And often times it's a good thing, but in my experience sometimes it's good to just throw your first instinct at the problem. So instead of determining it doesn't work in my head, I find the problems while running the code. This usually reveals more information than dismissing the idea during the planning process.

If you've ever witnessed an extremely fast command line whiz in action, you realize just how effective of a weapon their typing speed is. When the latency between knowing what you want to do and getting it done disappears, the depth at which you search a tree of possible commands and experiments increases.

In coding there are situations in which typing fast lets you experiment faster. For example, when you're trying to narrow down a bug to a few different possibilities, if you can type fast then you can quickly open up a new window and code up a little test application that isolates the problem. The thinking/typing ratio of these kinds of debugging experiments is low, and it has been my experience that most people are loathe to go and actually code up an entirely different program to do a quick test, simply because they don't want to do the typing.

In a nutshell, being able to type fast can remove mental barriers and change your approach to programming. Just look at how your approach to using a computer or browsing the Web changes when latency is reduced. Just because your CPU is idle 97% of the time doesn't mean that CPU speed is not important. Just because you spend more time reading a web page than loading it doesn't mean that latency isn't important.

That said, we as programmers should know you shouldn't waste time optimizing things that don't matter. If I had to guess, your ability to navigate with a keyboard (shift+arrows to highlight, control+arrows to move cursor by one word, etc) is where better optimizations can be made.

Using an IDE (Wing, for Python) that autocompleted locals without having to control-space to ask for completion helped a lot. Right now I'm doing mostly Java, and for some reason none of the big-name IDEs do that that I have been able to find. Kind of ironic given how proud most Java fans are of their IDEs.

We all know reading comprehension isn't a prerequisite for commenting on the l33t internetz, but you might want to read more than the title of the hackernews link before commenting.

My post was motivated by this tweet: http://twitter.com/jasongorman/statuses/5734675601

I didn't set up the comparison and there are certainly logical fallacies we can apply to that style of presenting questions and the implication that the answer to one implies anything about the answer to the other.

My main points are: First, that moving the chess pieces faster (in frequency, not in velocity) absolutely made me better at the game of chess, second, that if you are going to spend 8 hours a day sitting at a computer, you will never regret learning how to type.

Productivity is another question entirely.

One day I'll write about a past co-worker who could type 120 wpm and could fix any problem with one more 'if' (or 7).

For me, sitting and thinking of how to solve a typical coding problem for 10 minutes, rather than just coding it, is usually just 10 minutes lost. The problem reveals itself more as you code and so does the solution.

When I am in this zone of solving coding problems, I get very frustrated because I can't type as fast as I can think. My throughput is limited by my typing speed.

Some problems, especially when there are unknowns, require quite a bit of reflection. At those points, it's time to take a stroll and think.

I also experience what it's like to not be in this state whenever I switch to a keyboard with a slightly different layout than I am used to. My movements feel clunkier and I spend time context switching between being 'in the code' and being focused on where my fingers are on the keyboard.

For anyone who hasn't experienced this state due to poor typing skills, try to learn, it's worth it!

Analogously, the same could be said about a lot of things.

I don't know how much of it is about good programmers wanting to communicate their thoughts faster to the computer and how much is it about good programmers having written so ridiculously lot of code since their childhood that they just kind of get bizarre typing speed as a side-effect, but it's definitely both.

Being good at using keyboard shortcuts does not necessarily make one a good programmer and vice versa, but it certainly is an advantage to be able to quickly navigate your development environment.

I find that this helps me focus on higher level concepts instead of focusing positioning mouse cursor and clicking on things.

I never took a typing class, and I don't strictly touch-type according to the book (I might look down every six words or so), yet I still get about 55wpm. It's not 120, but then I don't have to wear wrist braces -- and I'm not in a race.

Fluency, absolutely. If a programmer is spending a lot of time thinking about typing, instead of "just typing", that's time spent away from the core problem.

While fluency and speed are related, and fluency may lead to or imply speed, the actual rate of typing seems (to me) to be unimportant.

I can definitely say that pair programming with a slow typist drives me NUTS.

I'm not sure I agree with the second bit of my summary.

From my perspective, typing is the busywork section of programming, the faster I can get it done, the more fun I'm going to have writing code.

However, I think that overall, having your IDE set up properly would be more advantageous that being a ridiculously fast typist.

Fast typing, however, does make you really good at writing documentation.

A lot of the time documentation is poor because the programmer is a bad typist (maybe just mediocre) and doesn't want to spend the time inputting the full length description of functionality.

If you are a pretty good typist, writing out the full description is as easy as thinking about it.