Does Typing Speed Really Matter For Programmers? 545
theodp writes "I can't take slow typists seriously as programmers,' wrote Coding Horror's Jeff Atwood last fall. 'When was the last time you saw a hunt-and-peck pianist?' Atwood's rant prompted John Cook to investigate just how important it is to be able to type quickly. 'Learning to type well is a good investment for those who are physically able to do so,' concludes Cook, 'but it's not that important. Once you reach moderate proficiency, improving your speed will not improve your productivity much. If a novelist writing 1000 words per day were able to type infinitely fast, he or she could save maybe an hour per day.' At 150 WPM, notes Cook, the world's fastest typist was still only 10x faster than Stephen Hawking."
text is one thing, symbols quite another (Score:2, Insightful)
Put another way, watch your error rate jump up when you quit posting on Slashdot and go back to your day job... if you have one, that is.
Not really important if somewhat proficient (Score:4, Insightful)
It does help a little to have some typing speed, but haste makes waste.
The most important factor in programming is not speed, but solid code. If you write lots of code, but the code is buggy, the time to track the bugs will easily eat any time savings gained by speed.
When it comes to debugging, thinking through the problem before trying to trace solve it will save more time then faster typing in the debugger. If by careful analysis, you can rule out 90% of the area of the problem, you have just reduced the time to track the problem by 90%.
Practically Immaterial (Score:4, Insightful)
If you're spending most of your time as a programmer typing, or even dealing directly with source code, then there's a lot more wrong with this picture than typing speed. Keying in code should be one of the most trivial parts of the job.
I'd say being able to type well will probably improve ones enjoyment. It may save a few minutes here and there. It is certainly annoying to watch someone else type slowly when you're waiting on something. Still, it has little or nothing to do with one's ability to program or ability to complete coding tasks quickly and well.
Code monkey or engineer? (Score:4, Insightful)
Don't measure WPM (Score:5, Insightful)
output = "We";
output += " should";
output += " really";
output += " be";
output += " measuring";
output += " lines";
output += " of";
output += " code";
output += " per";
output += " minute.";
System.out.println(output);
Programming != Data Entry (Score:4, Insightful)
Programming is the same. I would much rather a programmer actually put more thought into algorithms and design than churning out code. Ultimately what does it matter how many WPM a programmer can program anyway? Half the time they will spend their team using obscure symbols on the keyboards and actually reading / looking at cross-references and algorithms than actually punching in words. Even if a programmer can't churn out 50WPM does it matter providing he's reasonably fluent and doesn't spend 1 minute looking for the ! symbol?
Re:How Absurd (Score:5, Insightful)
Correlation:typing speed and coding experience (Score:5, Insightful)
There is a reasonable basis to assume that a slow typist is not a decent coding. After all, typing speed is something which is naturally developed as the person keeps hammering away at the keyboard. So, although typing speed does not guarantee coding proficiency, if someone does not pass enough time in front of a keyboard to develop any decent speed then it is expected that that person hasn't spent much time writing software. And if someone hasn't invested all that time writing code then quite certainly that person sucks at coding.
Its the Cognitive Load (Score:5, Insightful)
Its not the speed of the typing that matters, its the cognitive load. If you're spending all of your time trying to remember where the '}' key is, then you'll find it hard to keep your loop invariants invariant in your head. This leads to bugs.
If you type with two fingers, but can do it without looking or thinking about anything other than your code, then it doesn't much matter how fast you go. On the other hand, if you achieve incredibly coding speed by concentrating on your fingers, your code is sure to suffer.
Re:How Absurd (Score:5, Insightful)
Comment removed (Score:5, Insightful)
More important: Knowing the English keyboard (Score:5, Insightful)
Frankly, I can deal with programmers who are "slow" typists. Within reason of course, but in general, unless they're coding in Pascal (and even then, they will probably have learned by now how to quickly type those 'begin's and 'end's) or another language more suited to writing novels than code, what big difference will it make provided they know how to code?
What matters to me is their ability to use an English keyboard layout and do not have to insist in their own language. This becomes especially obvious in a multi language team (i.e. where English is the language of choice even if nobody has it as his native language because, well, it's the ONLY language they share), where you might be forced to use someone else's machine for something only to find out that you can't find ANY important characters because they're conveniently tucked away somewhere safe.
But more important, have you ever noticed how all those important brackets and punctuation that you NEED in 99% of the languages are near impossible to type without breaking your fingers on non-English keyboard, especially if that language has to deal with a lot of diacritical characters? On most non-English keyboard the { and } brackets are only reachable with the combination of Alt-GR and 7-0. And let's not even talk about the "Polish writing keyboard layout", which is a nightmare to program with. I still think they did it on purpose, I cannot imagine that anyone could actually code using such a layout.
If you are programming, and you happen to "suffer" from one of those layouts, try switching to an English layout. When I started to code, I was wondering who the FU.. could come up with the idea that { and } would be sensible to use for something you need, like, every other character. Once I switched to English, it started to make sense.
Re:Correlation:typing speed and coding experience (Score:5, Insightful)
There is a reasonable basis to assume that a slow typist is not a decent coding. After all, typing speed is something which is naturally developed as the person keeps hammering away at the keyboard. So, although typing speed does not guarantee coding proficiency, if someone does not pass enough time in front of a keyboard to develop any decent speed then it is expected that that person hasn't spent much time writing software. And if someone hasn't invested all that time writing code then quite certainly that person sucks at coding.
For my own personal case, I was a typist for about 8 years before I went down the coding path so my views might be a bit skewed and subjective.
With that out of the way...
I would tend to agree that there is a correlation of typing speed and software development experience (or there should be for a proficient programmer with a shitload of coding man-hours.) A person that doesn't spend enough time coding will simply code at sucking. And if that person does not have typing skills a-priori then that person will not have good typing skills. So, it is fair to assume that a person that works as a programmer should have decent typing skills, not because he/she needs them for coding, but as a side-effect of programming exposure, in a manner proportional to the amount of work hours doing coding.
That is, I would see it as suspect to see a programmer that cannot type proficiently, be it with all 10 fingers or simply with their index fingers. And I would not reserve that suspicion only to senior programmers but even to fresh-out-of-school ones. Not just good, but passionate CS/MIS students (either BS or AS degree seekers) will have sufficient coding hours under their belt to inevitably develop some typing dexterity. Passionate art students paint and sculpt a shitload. Passionate electrical engineers spend a shitload of hours building circuits. Passionate CS/MIS students spend a shitload of hours coding. In all cases, it is a shitload of hours beyond the minimum requirement to get a degree.
Will lack of typing dexterity mean with utmost infallibility that someone sucks at coding (or that was a slacker in school)? Obviously not. But it would be hard not to see it as suspect.
Another thing is that yes, typing dexterity helps with coding, with prototyping, with hacking. Yes, we need to plan and design before we code, but when you know exactly what needs to be done, or when you have a sufficiently good idea to start prototyping (or when you are in the middle of a hack that *must happen*), bro, you better be able to get those streams of thought fluently down to your keyboard via your fingers. If you have done coding work for real, getting down to some really nice (or ugly but necessary) code, you know what I mean - that you are in your mojo coding that thing down.
I cannot imagine getting myself into that *zone* of coding while struggling with the keyboard. No way, no how. I cannot see how someone could get into that *zone* without good typing skills. Period.
You don't need typing skills for design. But you certainly need it to crank some code when the muse inspire you. And if the muse doesn't inspire you often, you are either in the wrong career choice, or you suck.
Re:Depends on what language you use (Score:5, Insightful)
Most of the work do is maintenance. Finding bugs in 20 year old code. If I change two characters in one line on one day and close one bug, then thats a good day.
it matters a lot (Score:5, Insightful)
Touch typists generally use more verbose variable names and more comments, because it's much more natural for them to type a lot of words. This makes their code a lot more readable, which saves money in the end since a *lot* of the cost of software is in maintenance and the only performance factor that really counts is not cpu cycles, memory usage or bandwith utilization, but euros, dollars, rupees, yens or whatever your legal tender is. The programmer's time is (one of) the most costly aspect(s) of software development. A crufty codebase is much easier to read and maintian with comments *really* explaining fixes and variable names explaining what they're used for. I see so much code with comments like '// Issue #24654' or variable names like 'i' or 'j' in functions that span more than 50 lines (or whatever fits in one screen).
Of course there's more than typing speed involved in making maintainable code and I'm sure there are non touch typists who force themselves to make their code readable, but being able to type fast without thinking helps a lot.
Re:Programming != Data Entry (Score:5, Insightful)
A pianist is the equivalent of a data entry clerk. They have a sheet in front of them and faithfully reproduce what's on it.
Not quite. Once you move beyond entry-level competitions, it's simply a given that anyone and everyone can play anything given to them flawlessly. Your performance is judged on how you interpreted the piece, not merely on the fact you can read sheet music.
For example, listen to Rachmaninoff [youtube.com] playing his Prelude in C# Minor versus a newer interpretation [youtube.com]. Especially compare 1:58 in Rachmaninoff's piano roll with ~1:20 in Peter Roper-Curzon's version; there's a lot going on beyond technical accuracy.
Re:Depends on what language you use (Score:5, Insightful)
You can have that in any language.
It is simply a matter of choice. Most C/Perl people I know chose to have autocompletion off as it is not particularly useful (aside from getting braces right). C++ is on the fence. Most of Ruby developers I have worked with are definitely in the "my IDE types 2/3rds of the code for me" camp.
IMHO if your IDE is typing 2/3rds of what needs to be typed without getting it wrong then there is something fundamentally wrong with the language. The autogenerated verbosity simply does not need to be there in that case.
Re:text is one thing, symbols quite another (Score:5, Insightful)
Except, you know, every three seconds, unless you have remapped your keyboard so that the most important command in vim is not assigned to the far top left corner of the keyboard.
Re:Depends on what language you use (Score:5, Insightful)
I don't think so. I think it's something fundamentally wrong with the language if the IDE can't get 2/3rd of the typing right for the developer.
Take dynamic typed languages like Python, Groovy. Half the time I need to look up what the type is and what methods are there to use instead that the IDE is just auto complete it for me. With C++ you have static typing but the language is so complex that auto completion is almost useless.
I'm not a language purist. If the code is verbose but helps the IDE/compiler to understand the code better so the IDE can generate 2/3rd of my code for me why should I care about the verbosity? Actual, sometimes verbosity is a good thing, it helps to read the code and understand it later.
Re:Depends on what language you use (Score:5, Insightful)
A wall of symbols isn't preferable when you're trying to understand the algorithm that the programmer has implemented.
Re:Depends on what language you use (Score:3, Insightful)
IMHO if your IDE is typing 2/3rds of what needs to be typed without getting it wrong then there is something fundamentally wrong with the language. The autogenerated verbosity simply does not need to be there in that case.
Really depends on the type of autocompletion, IMHO.
I'll take (reasonably) verbose variable, function and class names over unix-C-style abbreviations any day - but it does require an IDE with decent autocompletion if you don't want to go insane... But given a decent IDE with "camelhumps" style autocompletion you end up typing less than the unix C programmer, while getting clearer source code.
I find that I spend a lot longer thinking about code architecture than on actual typing - even if using Notepad++ instead of an IDE - goes for all of the languages I use (C, C++, Java, C#). But it's definitely still nice having tools that reduce repetitive mechanical strain as well as letting me navigate large-ish codebases comfortably.