Is typing speed a factor in programmer productivity? Would you improve at chess if you moved the pieces faster?
Jason Gorman, who appears to be a relatively reflective programmer based on his blog and his twitter, tweeted this comment about chess a few days ago.
A bunch of people I follow ReTweeted, and it caught my attention because I used to think this way, both about chess and programming.
Now I don’t claim to be the greatest at either activity, but I’ve put some time and I have enough ability to claim to be above average at both. (Which is to say, I’m aware of my relative mediocrity when compared with real masters)
I’ve played chess off and on for years. I learned to play when I was quite young and I could usually beat other casual players quite easily. After losing to rated tournament players, I spent some time studying the game.
For a long time, I thought the best way to learn was to methodically look for the best move and I thought playing blitz games was somewhat degenerate. Luckily, someone convinced me to start playing blitz games regularly, and that accelerated my understanding of the game considerably.
I still play better when I take the time to be methodical, but that’s not the same thing as learning. I think the blitz games accelerated my learning for two reasons, first, because playing at that speed put that many more games, positions and patterns in front of me and two, because I didn’t attach as much ego to the games I experimented more, which led to that many more positions.
I do think there is a point of diminished returns to just move the pieces faster, and improvement is predicated on some reflection, but I will contend unequivocally that, unless you are a master, you will improve at chess if you spend a considerable portion of your playing time moving the pieces faster.
The same applies to code. You don’t need to type +100 words per minute, but if you can’t touch type at least 40-50 wpm, spend the 20 minutes a day for a month or so until you can. You will never regret it. (And I worked as a programmer for years before I could touch type.)
I would walk you through the arguments, but there is already a classic Yeggethon on the topic, which articulates all the positions I would and then some.
“Lose Your First 100 Games As Quickly As Possible”
–Proverb for Go Beginners
fate = will && choice || circumstance 
November 20th, 2009 at 10:34 am
The board game Go has a culture of playing at “brisk” pace in part for the reasons you describe: it accelerates learning the game but also makes it more fun, because your opponent won’t have to spend eons waiting for you to move.
If you’ve never played, give Go a shot: you might be pleasantly surprised by what you find.
November 20th, 2009 at 10:39 am
Actually, I think it’s pretty well established that blitz chess is useful mainly because it improves you intuitive understanding of chess positions, because you don’t have the time to calculate too many variations.
I don’t know if this insight can be translated directly into coding and typing speed. A more apt comparison might be to coding and (timed) coding competitions (of the Google Code Jam variety). Of course, the problem with that comparison would be that coding competitions tend to specialize for one type of problem solving, while coding is actually a much larger field. In chess, there is no such distinction, since blitz chess is no different in execution from normal chess.
November 20th, 2009 at 10:50 am
@Jake
I quite like the game of Go. I haven’t put in the time to be a strong player, but I do appreciate the game.
@Jon
I don’t think it translates directly across as an a metaphor either, but I do think writing more code will make you better at writing code and learning to type more proficiently can only help you do that.
Read the Steve Yegge link
November 20th, 2009 at 2:59 pm
Our team lead can’t touch type and is prone to making typos.
It’s painful when he’s driving exploratory code session or trying to demonstrate something, feel embarrassed for the guy 🙂
Not saying I’m better or anything, but when I’m doing the same it takes a quarter of the time, and that’s purely because I touch type and have my error rate down to a minimum.
The difference in programmer productivity between hunt-and-peck and competent touch typing is big enough that it’s a shame more people don’t pick it up.
Another thing I have noticed is that people who take a while to type things out, seem to be more reluctant to iterate and change the code, maybe that’s just anecdotal, but maybe there’s more emotional attachment to code that took longer to write 🙂
November 22nd, 2009 at 9:31 am
I don’t think typing speed is a factor, but it is a sign.
Someone who is good at coding has written a lot of code. It takes a lot of practice. They’ve also probably spent a lot of time in text editors.
If a programming isn’t fast at typing, and doesn’t use keyboard shortcuts heavily, then that tells me one of two things. It tells me that either they haven’t written a lot of code, or it tells me they don’t have that drive most programmers have to make their computing environment more efficient.
There are other factors as well. For example, when I do a Google Search, I press ctrl-K. Then I type in the query. Then my Google search is keyboard-shortcut enabled, so I press j until I get to the result I want. Then I press enter. I’m also very good at searching on Google, so I usually get the results I want on the first try.
If a saw a programmer click on the location bar, type in http://www.google.com, enter a bad query, click the google search button, scroll through the results, click the back button, click and drag the query, retype a new one that was also bad, then click the search button again, etc. I would have extremely strong doubts about the programming skills of this individual.
If you don’t know how to efficiently use a computer, how can I trust that you know how to make one? Would you trust a mechanic who didn’t know how to drive really well?
January 20th, 2010 at 6:11 pm
As a keen Go player and recovering chess player, I think blitz play can be helpful if your main fault is overthinking and losing on time. On the other hand, most people’s main fault is making bad moves because they didn’t think about them long enough, so a dose of blitz should be prescribed only as required.
Part of the problem may be a faulty ‘Think Like A Grandmaster’-style exhaustive move tree analysis. I think the good player uses his (developed) intuition to decide which moves look good and merit further analysis, without wasting time on moves which turn out bad. In other words, you need to use both fast-twitch and slow-twitch brain muscles in tandem: one guiding the application of the other. The word ‘shape’ is often used by Go players to express the intuitive and aesthetic sense that guides us towards certain conformations of stones rather than others.
I’m always surprised when I look at the game records of people on Dragon Go Server who’ve played literally thousands of games, and haven’t really improved in rating over that time. I suspect the reason is simply that they’re playing without thinking, and losing without learning.
I think the analogy with programming (though maybe not typing) works: a good programmer doesn’t think through every possible option. Her intuition (developed by long experience) tells her which are the most likely things to work, and she can focus her detailed analysis onto a small number of options.