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.
(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?
I'm a shitty typist, but a really good coder. I've tried to make myself faster, but I think my brain isn't wired for it. Occasionally my typing becomes a productivity bottleneck, but most of the time it just doesn't matter, as I'm spending 90% of my time figuring out what to type anyway.
Try a new keyboard. If you have a standard keyboard, get an ergonomic one. If you have an ergonomic keyboard, get a standard one. A few years ago, I found that using my laptop more frequently made me a better typist because I hadn't developed such bad habits and compressed layout drove my hands closer to the home row. Tape a piece of paper over the home/end/arrows/keypad/etc if you can't keep your fingers from wandering.
I think a standard laptop is pretty much the most ergonomic possible layout. The too-big keyboard is one bad thing about the standard layout and the mouse on the side is the other.
My wrists disagree vigorously with you, sir, on that. Standard laptops have terrible ergonomics not only related to key spacing issues (frequently too tight) but also the abruptness with which the keys stop (being as it is almost entirely rigid instead of the progressive resistance a good, say, Model M has).
I agree completely... The only thing is that since I've been using a colemak layout for some time now, when typing in qwerty on someone else computer I might look like a rather bad typist :-)
But yes, I think that someone who can't touch type can't concentrate as much on the code and is likely to make more typing mistake.
Heavily agreed on your first point. I don't think typing speed so much causes productivity - more like typing speed is an indicator of experience and interest in the subject matter.
Odds are, if you are actually interested in programming, you've spent an ungodly number of hours at some point in your life in front of a machine. You spend enough time in front of a keyboard and you will get really fast at typing.
And odds are, if you've never spent enough time in front of a machine to get fast at it, you haven't really had much coding experience.
I usually use a Kinesis Keyboard (http://www.kinesis-ergo.com/images/kb_adv-blk720x471.jpg) and a (rather customized) Emacs when I'm programming. I spend 90% of my programming time in front of my terminal - so it makes sense for me to optimize for that case instead of the general case.
When I program on a different keyboard/editor I am much slower than normal. I remember one interview I kept trying to use the Emacs kill ring (C-k) in Eclipse. (I just did a typing test and apparently I do hit about 60WPM on my laptop keyboard - but that's about half my real speed ...).
I have this problem with ctrl. I have a habit of making capslock act as another control key. When I get to other systems I'm constantly fumbling and turning caps lock on and off. However, I think it's pretty obvious from the speed of my fingers that I know what I'm typing but I just seem to be hitting the wrong keys.
And of course, switching editors and operating systems can really confuse you. I can't count the number of times I've copied something, gone to insert it into the editor, and realized that the system I'm on doesn't automatically copy highlighted text.
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.
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.
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.
I think the author's conclusion was that while being a fast typist doesn't make you a better programmer, being a slow typist will make you a worse one, as it will take you longer to commit your initial mistakes and iterate, akin to playing many games of speed chess to improve at chess.
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.
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.
I've never met a programmer who isn't a good typist.
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.
Or even better, moving your cursor without reaching for the arrows with emacs style C-f, C-b shortcuts (which also work in TextMate and various other editors) or vim's hjkl style navigation.
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.)
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.
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).
It depends on how you solve problems, and whether there are unknowns in the equation.
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'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.
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!
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.
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.
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.
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.
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.
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.
"Classic touch typists are at increased risk for RSI."
Link? A quick Google search only produced claims that touch typing reduces RSI, though I wouldn't at all be surprised that the evidence for those too would be the classic "proof by common sense".
I could believe that claim if by "classic touch typist" we meant "people who learned to type on a manual typewriter and as a result hammer the keys to within an inch of their life" (known to cause stiffness in finger joints, for example), but I doubt that's what OP was referring to.
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.
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.
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.
I can definitely say that pair programming with a slow typist drives me NUTS.
sigh 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.
Yep. I've been using dvorak for years and when the rsi hit, I tried 4 different ergonomic keyboards and experimented with tons of different approaches. The biggest contributor to my particular case seems to be independent finger movement. So switching to hunt and peck allows my entire hand to stay fairly relaxed and minimizes wrist tension. (I can also wear wrist braces this way.) That, combined with a keyboard with extremely light action, has been what's worked best for me thus far. Occasionally I break out one of my several Kenisis or other ergonomic keyboards and try going back to dvorak, but it always gets worse.
EDIT: I can't seem to reply to your question, so I'll add here. RSI can sneak up on you before you notice symptoms, and the symptoms can take years to appear. So I'd say, if I had done something different it'd be doing a daily stretching & strengthening routine even before I thought it necessary.
Shoot. Thanks for the info. Anything you wish you'd done earlier if you only knew? (That is to say, things you could have done to forestall the rsi.)
EDIT: Thanks for the reply in your EDIT. I've got mild symptoms that mostly only appear when I use a regular mouse or if I use my keyboard anywhere else besides the optimal height. Will start the stretching/exercises now. Hope it's not too late.
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.
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).
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.
(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?