Agreed; if you're truly horrible at typing, then you're probably not a good programmer. I did some pair programming with several of my interview candidates and here's what I saw.<p>(1) There's something important you can tell about a person's relationship to computers just by watching them type. The <i>terrible</i> 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.<p>(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.<p>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?
The author is making a flawed comparison. Typing faster isn't equivalent to playing blitz chess, it's equivalent to reaching down and moving the piece from the source square to the destination square faster.<p>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.
I think the analogy doesn't quite fit with typing speed in programmer productivity. If anything, it's analogous with time spent thinking on a problem. It's easy sometimes to spend quite a bit of time just determining how to attack a problem.<p>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.
Typing is an asset for those who use a command line interface as well. It's more than just a simple reduction of latency. If you are a slow typist, it's likely that your horizon of possibilities for leveraging the power of quick and easy shell commands is so small that you'd be better off using a mouse and an IDE.<p>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.<p>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 <i>entirely different program</i> to do a quick test, simply because they don't want to do the typing.<p>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.
I've never met a programmer who isn't a good typist.<p>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.
I spent a month typing 25wpm one-handed with my other arm in a brace. It was incredibly, incredibly frustrating -- but mostly because of the communication slowdown over irc, email, ticketing systems. (Then, as now, I was in a shared office so voice recognition wasn't really an option.)<p>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.
I'm the author.<p>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.<p>My post was motivated by this tweet:
<a href="http://twitter.com/jasongorman/statuses/5734675601" rel="nofollow">http://twitter.com/jasongorman/statuses/5734675601</a><p>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.<p>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.<p>Productivity is another question entirely.<p>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).
It depends on how you solve problems, and whether there are unknowns in the equation.<p>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.<p>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.<p>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've noticed that by being a good typist the keyboard is almost like an extension of my mind. I simply don't notice it at all. When combined with a powerful editor like vim, it's almost magical how well integrated I feel with the code that I am writing.<p>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.<p>For anyone who hasn't experienced this state due to poor typing skills, try to learn, it's worth it!
Typing fast doesn't make you a good programmer though good programmers usually type fast. The only conclusion you can draw is that if you see someone typing horribly slow you can probably treat it as a warning sign.<p>Analogously, the same could be said about a lot of things.<p>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.
More important than typing speed is the ability to use shortcuts. Programming tends to involve short statements and many movements around a file and between files, instead of writing long prose as you would when writing a book.<p>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.<p>I find that this helps me focus on higher level concepts instead of focusing positioning mouse cursor and clicking on things.
Classic touch typists are at increased risk for RSI. I'm fairly convinced of that fact. Even though I don't know if there's real research to back it up -- I'd rather not take the risk. For that reason alone, I do not wish to learn.<p>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.
Speed? I doubt it.<p>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.<p>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.
Only in the embarrassing overstatement. If it takes you three days to type 30 lines of code then yes it has an effect on productivity. In normal human typing range say 30WPM to 100WPM. It takes 1 min for the fastest typist then the slowest typist takes 3 min. for the slowest.
Totally broken analogy. If it took a significant amount of time to move your chess piece after you'd decided what to move, then yes, moving it faster would be a good thing.<p>I can definitely say that pair programming with a slow typist drives me NUTS.
<i>sigh</i> I had to switch from being a really fast dvorak typist to a hunt and peck querty typist due to RSI issues. Luckily my particular job doesn't involve churning out huge swaths of code, but I definitely feel handicapped.
I think it would only effect productivity if one is horrendously slow at typing. There are too many other items that fall under the umbrella of productivity that being an average "hunt and pecker" won't do one much harm.
So... yes. Doing more programming makes you better at programming. People who type faster can technically do more so therefore they are better at programming.<p>I'm not sure I agree with the second bit of my summary.
I've got a problem with ideas such as this. How dare we judge productivity through typing proficiency - while we still haven't managed to properly define programmer productivity?
I touch type about 100-120 wpm (with lots of caffeine and a tail wind a bit more...), but when i am trying to write code I spend as little time typing as possible.
I'll sit there and think about it or write the code down on paper or draw a little diagram or something, then I'll run it in my head. (Sometimes I just do all of it in my head).<p>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.<p>However, I think that overall, having your IDE set up properly would be more advantageous that being a ridiculously fast typist.<p>Fast typing, however, does make you really good at writing documentation.<p>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.<p>If you are a pretty good typist, writing out the full description is as easy as thinking about it.