Does Typing Speed Really Matter For Programmers?
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."
ps - first post!
You'll naturally be a better programmer with a Model M, because you'll be able to kill your programming rivals with one fell swoop.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
'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?'
When was the last time you ran a program where the WPM of the developer affected the quality of the code? Because the frequency of and careful regularity and emotion seriously affects piano performances whereas the symbols per minute inputted by a developer is independent of the speed, quality or maintainability of software. Sure, you might put forth that they can produce much more code or much more comments but let's face it: I'll take quality over quantity in regards to code any day of the week.
A short simple anecdote was my Greek professor in college. Taught me pattern recognition and I went to his office hours where he was pecking away at the keyboard having just been forced onto English QWERTY. The old man still wrote some pretty badass pattern recognition algorithms in Matlab for the course. Might have taken him all week to peck them out while looking at some recently published papers but the stuff was pretty efficient and easy to read for Matlab. I took him pretty seriously.
At my high school, in order to take advanced placement computer science courses, you had to pass some WPM typing course. Rarely have I felt a course to be such a complete waste of time and genuinely a turnoff to people looking to study programming.
My work here is dung.
String output;
output = "We";
output += " should";
output += " really";
output += " be";
output += " measuring";
output += " lines";
output += " of";
output += " code";
output += " per";
output += " minute.";
System.out.println(output);
Do not anger the worm.
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.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
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.
Of course it matters. Sometimes. Your 'rate of creation' is simply the min(rate_of_typing, rate_of_thought). If you can type faster than you are currently thinking/creating/"solutionizing" then no, it doesn't matter, and there are a lot of times during code creation where this is the case; you need time to noodle, try things out, think about a solution, need some time. But, there are times where you know EXACTLY what you want the code to do/be/look like, and those times your typing speed can be the bottleneck, and there are a lot of times during code creation where THIS is the case too.
Before you design for reuse, make sure to design it for use.
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.
http://michaelsmith.id.au
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 playing his Prelude in C# Minor versus a newer interpretation. 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.
DATABASE WOW WOW
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.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute