Slashdot Mirror
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!
Except in Java with all the tools you have at your disposal, if you're typing 1/2 or even 1/3 of the code you're writing, you're doing it wrong.
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'm a programmer, and I think I type very well; much better in fact than people who can touch type - but not because I type faster. The way I type does not requires me to bend my wrists; i've gotten pretty fast without stressing my wrists, while people I know have been forced into an early retirement because they can no longer type.
The first rule of typing should be: DO NO HARM,.
after that, suit yourself.
'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.
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%.
Fight Spammers!
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.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Atwood's opinion is about as intelligent as saying "You can't be a good architect if you don't draw fast." Typing is an essential part of the process of being a software engineer, but typing speed is important only to the most brainless parts of the job -- parts that are likely either done by code monkeys or while the engineer is mentally processing the rest of the design.
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.
Good programmers spend the vast majority of their time thinking, not typing. A better music analogy than Atwood's hunt-and-peck pianist is composers. Composers reiterate over their ideas for a period of time then write to paper only when they feel the ideas may be worth committing to.
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. The person who composed the sheet music on the other hand may not even play the instrument it's designed for. I highly doubt composers of classical pieces were capable of physically playing every instrument in an entire orchestra, but based on what they wanted to do they could create the notes for it.
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?
I find that I don't type very fast at all when I'm writing code; after all, the limiting factor there is how quickly I can think through what I want to do, not how quickly I can twiddle my fingers. I suppose if you're working from a very detailed design document you would need to be able to type quickly, but if it's that detailed why isn't it already a program?
On the other hand, I do find that I only rarely have to go back and re-write large sections of code; usually the worst that happens is that I need to run a regular expression over it.
The problem lies in the mentality 'I'm a java programmer, *therefore* I use an IDE with autocompletion'.
Religion is what happens when nature strikes and groupthink goes wrong.
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.
to a point. If you're horribly terribly slow at typing on a computer, you won't be able to effectively execute ideas as they happen, sometimes you really just need to pound out that ~150 lines of code you have sitting in your brain queue, if you have a significant lag between the time of inception and the time of completion, you're stuck on the same idea for a long period of time -- you can't quickly type it up, compile/test, debug it, then move on all during that while you had in mind what you needed to do next. Instead you're hopelessly focused on the single task at hand.
However, how many programmers spend so little time working with computers that they don't have a natural typing speed of 60+ WPM? Surely most do, although I don't know anyone that can type as quickly as I do, they aren't slow at all. I'd imagine at around 50 WPM it ceases to matter really except that at 110+ you end up doing a lot of little corrections and formatting changes to your code. I find myself re-editing my code in several iterations at times, doing my thinking in text rather than all abstractly in the mind (it's easier to add up a large column of numbers on paper than it is in your mind btw), write out a quick obvious case implementation, do a quick optimization pass, then debug and write a unit test if needed.
I think the problem with counting in lines of code is that 1 BLOC != 1 GLOC. (bad vs good). 10000 bad lines of code can probably be replaced realistically with 1000 good ones (you may get ratios of up to 100:1 if you see code like on TDWTF). If a programmer consistently pumps out 5000+ lines of code a day with no problem may be far less productive realistically than someone who only makes little more than ten percent of that but has fully debugged it, implemented strong algorithms and well researched data structures and design patterns, and even has a unit test to verify that future modifications work as expected. In the end, it matters, sure, but I do think it's more about the intelligence and skill of the programmer, not how quickly they type.
Any reasonably intelligent person should be able to find the flaws in Atwood's analogies and synthesize several decent counter-arguments by themselves. The notion is ridiculous on its face and if the quality of this guy's analogies is any indication of his mental acuity then I'm surprised anyone reads his blog at all. I'm not sure why such a laughably flawed statement should prompt anything but derision, but Slashdot being what it is today, I suppose it is the right place for such a discussion to take place.
Because poor typing skills will lead to you writing less readable code with a lot more shorthand. Shorter variable names, shorter function names, if you don't got good typing skills you'll end up coding using lots of do( x ); where parse( record ); would be far better. You can pretend it doesn't happen, or you can pretend it doesn't matter, but you inevitably drop the "fluff" because it's "slowing you down". I've tried it, it actually requires more typing to write code you'd want to come back to later, all that context that's spinning up in your head telling you what all the variables are and the abbriviations mean will be lost. Being able to type it out quickly and effortlessly without losing the flow of the code you are working on is a big advantage. It's not the typing speed itself though, it's getting to the point where your typing doesn't interfere or slow down your thinking. But when you're typing naturally without thinking that is a highly skilled typer..
Live today, because you never know what tomorrow brings
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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
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.
When I was younger, I did a number of projects in APL. Typing speed was more likely to be characters-per-minute, not WPM. For the most part, touch-typing APL is a null concept; almost everyone spends a fair amount of time hunting for the particular special symbol that they need. APL might be the only programming language where it would be faster to scribble stuff on a touchscreen with a stylus than to use a keyboard :^)
This is not an argument FOR java. This is an argument against it.
"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."
So, you're saying it would have taken you half a day to add an "I" between "work" and "do" in the first sentence of your reply? That's slower than any hunt-and-peck typist I've ever met.
"National Security is the chief cause of national insecurity." - Celine's First Law
this comic seems to be accurate and appropriate every time a slashdot article title ends with a question mark...
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
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.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
You are not a professional programmer until you realize that most the work is debugging.
Democracy Now! - uncensored, anti-establishment news
The challenge is finding the bugs
http://michaelsmith.id.au
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.
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
A wall of symbols isn't preferable when you're trying to understand the algorithm that the programmer has implemented.
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.
Coffee-driven development.
How many programmers do you know that use Dragon Naturally speaking? Face it, a lot of programming and markup is mundane shit. Say you are a hunt and peck typist and you'll eventually need to write 4000 lines of code, tell me you are not really any better than if you can type at 40 wpm vrs 10? Is a mechanic with 2 fingers going to be as productive as one with 10? We have a word for this, its called a disability. If you are a hunt and peck typist you owe it to yourself to learn touch typing. It only takes 2 weeks, one hour a day, to be at least 25 words per minute and then after that you only get better. Of course there is code that requires absolute brilliance to come up with a single 40 character line. It might take an hour to make that line. I'm not saying I'm a brilliant programmer, because I am not, but I do know that if I'm having problems with a single line of code I might have to rewrite it 10 times to get it right. But we are not all algorithmic scientists working on global illumination shaders.
> why should I care about the verbosity?
one word. maintainance.
typical code spends less than 10% time in development. the rest in production and maintenance. IDE (or a tool, as in RoR) generated code is still code that has to be maintained. the more code you have, the more bugs you have and the more shit you have to wade through to find your bugs.
Also, if something like an IDE can generate the code, isn't that by definition 'boilerplate'? if it's boilerplate, why couldn't it be part of the language itself?
compare and contrast the @synthesize in ObjC with the getters/setters in java. Sure, in java the IDE generates those for me. but I still have to wade through those in the source code to find the method I actually wrote. Couldn't java just implement some default implementation for getters/setters through some annotation? a la POJO annotations for EJB - compare that to the XML mess that was there before.
that's just one example.
to me, if i'm copying and pasting code anywhere, i'm doing it wrong (code duplication, bug duplication and what's worse, fixing one part doesn't mean i've found and fixed all the same bugs). but java just begs copy and paste. sure there are great tools (Netbeans, Eclipse) to help mitigate that - but that's just it - all the tools are still mitigating a shitty language.
i'm not a language purist either. over however many years i've been doing this, i've found that there are some languages that let me express my thoughts quickly, concisely and elegantly whereby i don't even have to step through code in a debugger to see where i messed up - it just becomes obvious on re-reading the code. java is not one of those languages.
This article has a good discussion on tool mavens vs language mavens. OP is obviously a tool maven. I'm a language maven. I also think that being able to have the typing happen without having to think about it makes coding a lot more natural and enjoyable. But then I use emacs...
Languages aren't inherently fast -- implementations are efficient