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!
The most important this is to be lazy very very lazy.
Yes, for Java you'd better be able to type 100 WPM.
Me, I prefer C, C++ and Perl. Much more expressive and dense source code. Yes I'm a lousy typist.
thegodmovie.com - watch it
Writing an essay is entirely different from writing a function in C or Perl. Unless the essay in question is rich in physics or mathematical symbols, the author will be taking his/her fingers off home row a lot less than most modern programmers.
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.
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 tyep fast, ot see it and still produce Greay cdoe!
'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
So the ability to lay out logic, proper code structure, or beautiful code, as fast as possible is the epitome of programming?
I suppose of the millions of programmers on the planet, none should have to reevaluate or rewrite their code at any point as well. We're all pinnacle programmers from the gate, aren't we?!?
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.
Speed is something you get by typing more, and programming skill comes from programming more. Luckily, unless you're programming with punched cards, the latter helps the former.
So what's the debate again? (Obviously haven't RTFA)
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.
... "editor" typing speed is even more so, I can't believe how many times I have seen coworkers blindly typing everything out where a macro could have made them type 1/10th of the characters, not to mention how much faster they could be with an editor that supports rectangular copy+paste, automatic indenting, justification, alignment, auto-complete etc. etc. etc.
A medium-speed typist that's fully proficient in their editor of choice can output a LOT more lines of code than a super-fast typist that treats their editor as a dummy typewriter. Of course if you have a fast typist fully conversant in their editor (especially emacs ;) ) it can make their productivity quite amazing when they are "in the zone".
-- the cake is a lie
Anyone who thinks typing ability is important to creating useful computer program is probably a clueless programming wannabe.
My most important work in the course of developing a program happens during requirements gathering and algorithm development which is done with a pencil and paper.
Anyone who just sits down and starts typing (for anything more than a couple lines of shell script) is an uneducated and inexperienced novice and anyone who hires someone who designs and writes at the keyboard deserves what they get.
Signed,
A retired old fart who began with FORTRAN and COBOL and is still writing personal use stuff in C++ and Python
Modern IDEs tend to auto-complete so much that it really isn't a problem, even in verbose languages like Java. Then there are of course those languages that are so abstract and dense that it will never matter, like say Haskell.
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
TFA references masters in their fields and people of higher mental abilities and tried to say that it does not matter how slow you push the keys down, it's what you put down. Well then why did they not even consider what kind of mental load hunting and pecking for keys puts on the typist? I don't know about you but when I type(10 fingers) I do little to no thinking of what keys I'm pushing and spend my mental time on the concepts I'm putting down. I may suck at what I put down but I'm not spending time looking for a key or backspacing because I typed wrong and even looking for the backspace key when I do mistype.
So if coders write their code down on paper and then transpose it into the computer, TFA is good enough but I doubt that's what is happening. If they code using UML diagrams then that would be helpful too but I don't see much of that.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
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.
Speed typing isn't necessary, but when you're trying to debug something thorny and you're waiting for that one guy to stumble through commands.... hunting... pecking... typoing again and again while you have nothing better to do than resist the urge to rip the damn keyboard from his hands...
I've seen bad typing waste as much as 50% of the time of four rather well paid people.
Okay, so that's still better productivity than most meetings manage.
I just finished raCoders at Work, Reflections on the Craft of Programming.
The book is a series of interviews with influential programmers and several of them admitted to being slow typists, and thought it didn't matter that much.
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.
That is assuming that a novelist already knows on what to type and does not change his story while he is typing.
Perhaps they think of "journalists" or a better name would be "news paper fillers". A novelist will be payed by quality more then by quantity. A newspaper filler will be payed more by quantity.
Just typing this short piece I went back 6 times to change (small) and I already knew what I wanted to say. (and changed 5 to 6, because I added the word small.)
Don't fight for your country, if your country does not fight for you.
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.
For the code itself, as other people have said, I would far prefer an expert to hunt-and-peck 100 lines of awesome than have some random person bash out 1000 lines of WTF at 150 WPM. Where the real difference comes in IMO is the documentation/commenting of said code. In my experience, if someone has difficulty typing quickly they are far less likely to document and comment their code as frequently as someone who can type well. So it's still worth learning even if you are an expert :)
Build a man a fire and he'll be warm for an hour. Set him on fire and he'll be warm for the rest of his life.
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
http://dep.posterous.com/not-using-scrollwheel
Typing speed matters especially when you are pairing with someone on some problem.
I think it matters a lot. Here is my thoughts about typing speed:
- Speed is good, but think first, program second.
- If you can get what is in your head down into your editor faster, you will get quicker feedback on your code. You can then try out more stuff in a shorter timespan.
- Not all of your code will be rocket science. A lot of code is and will be boilerplate code and the faster you get to get it down and out of the way the better.
- If you don't have quick editor speed you probably don't know your editor and you end up doing stuff you should not have done. (your editor should)
- You should document your code, maybe on a concept level (on an wiki or something similar). Then you need to write and if you don't type fast you'll use forever on this.
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.
Once those fast typist have produced all those shitloads of code, the program goes in maintenance. And there you are happy to produce five lines of code at the end of the day, thinking that the same amount of thought on ten times less code would have produced better results.
...any branch of CS/IT, study of which includes time-limited exams during which you have to churn out large quantities of functional but utterly boring code.
Oh, and also if you happen to be applying for a job of John Travolta's personal coder.
Mit der Dummheit kämpfen Götter selbst vergebens
I'd argue that for programming, in which typing is a necessary step while not being the desired product unto itself, typing slower or typing faster is not the point. Effort spent typing is the point. As a distraction, typing becomes problematic for programmers. Being one myself, expressing a complex relationship in code would be hindered by any increase to the distraction of typing that code.
Expending ten times the effort on typing, would quickly reduce the quality and cohesiveness of my code -- which is why I've developed platforms with a huge increase in code density, thus requiring me to type even less -- equating to greater typing speed not unlike a having richer spoken vocabulary.
Yes, it matters. Not to an infinite speed, but to a speed congruent to the complexity of the code being written, or to the speed of the mind conceiving that complexity -- whichever is lesser.
This is reminiscient of the qwerty vs dvorak scenario. While any human sufficiently adept at typing will reach similar rates on either layout, the dvorak results in a reduced amount of finger movement, resulting in greater stamina without increased endurance. My next keyboard will take that further, inspired by the dvorak layout's optimization for English by adjusting some of those optimizations for programming, specifically within my platforms.
What happened to K locks?
I think what happens is that it takes practice to make a good programmer, and by practicing programming (writing experimental code, etc.) one naturally improves his/her typing speed. But speed, in itself, should not affect programming skills too much as long as it's not slow enough to disrupt one's thought flow.
I can't imagine WPM as a measure of who is the better programmer. At the same time, I can't imagine anyone typing all day every day who was still a hunt-and-peck typist. I'm not saying that they're no good, I'm saying that if they had any sense, they'd do whatever it took to learn touch typing. You don't have to manage a high WPM: I was at no more than 30 WPM for years, until I had practiced enough that I'm in the 70-80 range now. But if you're using a keyboard all the time, it only makes sense to have learned to use it well.
I had to take "Secretarial Office Procedures" in High School to learn this stuff. In spite of the name, the skills have served me very well. I don't think anyone can complain about having to buy typing tutor or whatever and spending a couple of weeks learning it. I certainly wouldn't take someone seriously as a skilled computer user if they couldn't manage touch typing at any WPM, unless they were somehow physically disabled.
Because the same flawed logic applies.
This is the most amazingly ridiculous keyboard I've ever seen.
http://www.keyboardforblondes.com/
If you're a zombie and you know it, bite your friend!
I would definitely put more of an emphasis on typing accuracy than speed... It saves more time/money in the long run. You can be the fastest typist in the world but if every 3rd key is the backspace then you're losing some serious efficiency.
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.
Atwood's original point is that he personally can't take people seriously if they can't type yet intend to make a career out of programming. I don't know what he means by "slow" but in my mind it's someone who is literally looking down at the keyboard looking for the right buttons. Clearly, if the user is physically unable to type quickly, or is using a new keyboard layout, it's a different matter.
Some brilliant programmers may not be able to type but I wouldn't be able to take them seriously if I was hiring for a position -- unless the guy was good enough that I would be willing to hire a transcriptionist.
On the other hand, for everyone saying "I'd rather have 10 lines of excellent slowly written code than 100 lines of crap", I don't think he ever said that being a fast typist makes you a good programmer. I'm sure if you asked, he'd say "I can't take people who write bad code seriously as programmers."
I did not become a programmer because even though I could come up with some of the best algorithms for my assignments typos and syntax errors were just unbearable. It was before the proliferation of IDE and syntax highlighting...
I graduated from HS over 30 years ago, and I still remember touch typing as one of the two most valuable classes I ever took. Touch typing skill are valuable because it does get one away from hunt and peck. But typing speed has absolutely nothing to do with coding, since when I code, 90% of my time is spent looking at the screen and thinking about the code. Half of the rest is spent copying/moving code segments around. The 10% spent entering text are done a line or two at a time. The speed increase made by touch typing is not significant.
âoeAny society that would give up a little liberty to gain a little security will deserve neither and lose both.
Fingers on the keyboard
Can anyone explain me this stuff? The top layout thingie is the standard one I found on wikipedia, and I find it horribly unnatural to use, therefore I created my own distribution of finger use pictured on the bottom, which feels much more comfortable. The finger names in the picture are in Norwegian, but they correspond from left to right on your left paw. The best example is the C button. Even the thought of using the middle finger for that button makes me shrug, therefore I rather use the index finger.
(As a side note, I do use the Dvorak layout, but this is not a question about layouts.)
Dvorak on Doomtech
I assume that anyone, barring physical handicap, can learn to type and will progressively get faster until they can express their thoughts somewhat directly. It's not a matter of the "think vs type" time ratio, it's not a matter of the logic acumen, it's not a matter of the raw speed. (Obviously the logic acumen is most important of all, but that's another skill that is usually developed over time.) I must say that without other information, I must assume a slow typist is an inexperienced computer user. Reminds me of the scene in Brazil where the co-worker claims he's "a bit of a whiz with these things" while hunting and pecking incompetently.
Learning ANY physical skill is easier if you are not paying 100% attention to the skill itself. Learn to roller skate by chasing a tennis ball around a parking lot. Focus on the ball, and your feet will "figure it out" on their own. Back in the ages of MUDs (that's MMORPGs in all text format, for you kids out there), I found the fastest way to learn to type quickly was to try to hold a conversation real-time. IRC is a sufficient alternative. If you don't want others to get bored with your slow responses, you will naturally speed up your typing.
[
I'd agree with the guy based on the premise that if someone can't type quickly then he mustn't have spent a lot of time typing ergo hasn't spent a lot of time coding.
That's a reasonable assumption to make, however this is not to say that someone who types quickly is a better coder- - but someone who keeps staring at the keys[1] would be a bad coder.
Does this make any sense to anyone else?
[1] Unless you gave him an unfamiliar or in some way strange, to him, keyboard.
I find myself cleaning up the technical documentation of very smart people. I describe it as thus: "They know exactly what they're talking about, and they assume I do as well." But writing a technical manual isn't the same as writing code. I'm a technical writer, not a coder, so I naturally hum along at 60 WPM without even thinking about it. But the coders whose writing I decipher are all hunt and peck typists at best. Does their slow typing affect their work output? No, because it's clean, brilliant code, and because I'm paid to translate it into English for them. (Or more precisely, document the steps that includes their coding.) They can't do what I can do, but then again, I can't do what they can do. They're smarter than me in many respects - I can't think in looping algorithms or batch script processes. But I'm a better writer, and subsequently, a better typist.
Occasionally living proof of the Ballmer peak.
I've always been a very fast typist; many people I've worked with have noticed and commented on my typing speed. An Indian contractor I was working with wanted to know how I got that fast -- had I taken a class or used some typing training software that he could use so he could become as fast. I told him it was just something that came naturally to me and that I didn't really think typing speed was very important for software developers, because actually typing in code is a very small part of the process. But it seemed to bother him a lot. He said that if he was typing in a "for .. next" loop and I was typing in a "for .. next" loop, I would get mine done faster. I kept telling him I didn't have any special tricks for typing fast and that he shouldn't worry about it. But he just wouldn't buy it; he genuinely seemed to believe I was withholding something from him so I would have what he saw as an edge over him. I've always thought that the importance he attached to typing speed was kind of strange.
I think the major factor is to have the keyboard not be a barrier to thought. I have been typing for over 40 years; I learned how to type "properly" in Typing Class in high school on old Underwood manual office typewriters.
I type automatically, meaning that I don't think about what I'm doing any more than I have to think about breathing. The words just appear on the screen in front of me as I make decisions about what I want to say. This allows me to think about what I'm creating (source code, email message, instructional write-up, etc.), rather than worrying about the mechanics of actually typing it out.
The point being that when the keyboard is not a barrier, it frees you up to think about what you're trying to accomplish and the rest just happens.
This, to me, is the value of knowing how to type properly if you're a programmer. You only have to do one task -- deciding how to write the program -- instead of both that and having to figure out how to type it up as well.
If you're a zombie and you know it, bite your friend!
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
What if I have three pages of documentation open in a web browser, my IDE, and other software development programs running?
I can't envision a poor typist switching applications, editing code, and using other shortcuts without being miserably unproductive.
Being miserably unproductive would definitely effect the quality of the code.
I know of many cases in the last 20 years when my fingers have been blazing as I'm coding. Not writing code from scratch - but doing lots of find/replace (before IDEs had all these refactoring helpers). I can't remember the specific scenarios, but I know there have been times when my coworkers have heard the keys blazing non stop at high speed for several hours and wondered what the heck I was doing.
I seem to recall it around lots of manual typing of database field names in multiple places, maybe adding or reordering or renicing :-) something in some way.
When I am writing code I spend a lot more time thinking about my approach than I do implementing it. That is where the latency is.
I'm not even talking about the design or whiteboard phase versus final implementation. I'm talking about the translation step from brain to keyboard. Even if you think you know exactly what you want to do, I find I am constantly thinking about it, refining it in my head and on the screen until it fits what I imagined. Sometimes that takes a very long time. Very little of it is spent typing.
If I may make a lame metaphor of my own experience, not so long ago I was working on something that was very I/O bound. I made some efforts profiling and improving the efficiency of the CPU-bound tasks that did exist. I reduced the algorithmic complexity of a lot of important-seeming tasks. In the end this didn't make much a difference, because I was still doing lots of I/O, and that drowned out everything else.
In this analogy, typing is CPU. Fetching the code from your brain is I/O. It doesn't matter as much how fast you type, because even with the fastest fingers they will spend a lot of time "waiting" for the ideas to come out of your head. This will easily drown out typing speed.
but for random bursts of input when altering or creating new code. Sure speed helps at those times, but not for long times like typists. More like video game accurate shooting from time to time than constant drums playing.
^[:wq!
Among my coworkers I seem to see a correlation between their ability to type, their zeal for nice code and even how neatly their cubicle looks.
-Max
A true hunt-and-peck typist is concentrating on finding the letters when typing. A touch typist devotes almost no conscious effort to typing. If I try some unfamiliar keyboard layout, so that I can no longer touch type, I find that my coding has two mutually exclusive phases--thinking and typing. When using a layout for which I can touch type, there is only one phase--thinking. Thus, I think it is important that a coder be able to touch type.
As far as touch typing speed goes, it probably doesn't matter too much, as long as it is fast enough to keep up with your thought. I don't think it is valid to just look at how many words could be typed at different speeds and note that the difference at the end of the day is not much. If the typing is slower than the thinking, you will find yourself having to interrupt thinking to let the typing catch up. That will be annoying, and will, I think, reduce productivity more than just the raw difference in number of words that can be typed would account for.
Another factor to consider is communicating with others. Up until recently I had coworkers who worked thousands of miles away. We did a lot of communicating over a company IM server. It always annoyed me chatting with coworkers who typed noticeably slower than me.
If you are based in the US but work on Asian servers than Thai ping speed may well matter.
thank God the internet isn't a human right.
You are not a professional programmer until you realize that most the work is debugging.
Democracy Now! - uncensored, anti-establishment news
Touch typing isn't just about speed. It's also allows one to type without looking at the keyboard. I've seen lots of programmers who could hunt-and-peck at 30+ words per minute, but they couldn't do so while looking away from the keyboard.
Although raw speed isn't that important when entering code (since typing speed generally isn't the limiting factor in creating software), the ability to type quickly and accurately without staring at the keyboard is a huge advantage while doing other tasks (typing documentation, typing notes at meetings, things like that).
A programmer who can't touch type is like a carpenter who can't use a hammer.
Well, it sure doesn't affect quality per se. But does it matter if a carpenter knows how to handle his tools or not? Yes it does. Is a carpenter with a high hammering speed more likely to be proficient with his tools than a slow one? Most definitely. So does hammering speed matter for carpenters? Overall it surely does, yes.
Programming and typing speed? Very much the same.
Conversation using typed text is the most important communication method in any engineering. E-mail, irc channels, instant messages, corporate MS Office Communicator, bug reports, version control commit messages, source code comments, plain old SW design document, meeting minutes...
Almost any professional (meaning getting paid to do it, not referring to quality in any way) software development involves more writing normal text than source code.
Typing speed for normal text matters, and if it's satisfactory, then typing speed for source code follows from that, and will be adequate.
Oh, and "normal text" means understandable normal text. It doesn't allow too many typos, nor too shaky grammar, before that'll start to hamper communication.
90% of programming is knowing how to type.
touch typing is where you feel where the keys are (touch)
I use a different type of typing where I don't have to know where the keys are or look at them either and use, well pretty much anything.
I find this much better for programming than when I've tried to use touch typing, as I can type with one hand and hold a phone or use a mouse and also because a lot of the keys are pretty far away from the traditional touch typing bumps on the keyboard I don't have that restraint either.
There is a name for it (basically typing in a trained intuitive manner rather than by touch) but I can't find it. (maybe on the touch typing discussion page on wikipedia as I think I raised it their once. but it appears to have gone.
thank God the internet isn't a human right.
ah it's called blind typing. Touch typing is a subset of blind typing where you use touch instead of sight.
Though you can blind type without touch typing.
thank God the internet isn't a human right.
Schlemiel the painter would be proud. Rewriting this with a block of comments describing the problem with this code, though, might be a reasonable excuse for learning how to touch-type prose.
Take the project you're on, and do the maths on your source base. The project I'm on has been under an ongoing onslaught of development for 3 years, and the group is clocking about .3 wpm. I do agree that different situations will want a different array of complementary skills in the development group, but if a 10-year developer walks in with a CV and references, the last thing I'm going to do is give him a typing test.
I completely agree with this. Its not about quantity of lines-of-code or words-per-minute, its about being able to hold an idea as you execute it. Ive seen developers using a laptop keyboard and a trackpad losing focus as they try and implement something and they stuggle with the keyboard and moving the mouse pointer. Someone who has the right tools and knows how to use them well can focus on the higher-order problems more easily. Its the same in any profession.
Typing speed has no bearing on how good a programmer is. The time spent actually typing lines of code is not that significant when you factor in design, unit testing, debugging, integration, and so on. BUT, the best programmers tend to spend a LOT of time at the keyboard. They become fast, even if they can't touch-type, their hunting and pecking will become speed pecking. So, while I agree that you don't need to be a fast typer to be a good programmer, I've never met any good programmers that were not also fast typists.
"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety"-B.Franklin
The real reason to concentrate on typing speed is that it allows you to detect people who have never written any code from those that have written large amounts of code. If you write code every day on your life for 40 years, it's pretty certain you have learned to use computer keyboards very efficiently. This shows in typing speed. Even if the programmers would not know anything about how speed-typing should be done -- once they keep writing code over and over again, they will figure out a way to do it quickly. Everyone has different way to do it, but they definitely can do it quickly.
I was trained on manual typewriters and then selectrics in the mid-80's my weapon of choice still to this day are IBM Model-M's ( Unicomp makes them now ). Accuracy is way more important than raw speed when coding. Anything else I can do 85+ words a minute on my Model-M.
I think there's a big difference between a "slow" typist and a "hunt-and-peck" one. Someone who can touchtype, but only types 35WPM still has a huge advantage over someone who hunts and pecks. After that you get diminishing returns---if you type faster than you can think, then typing that fast isn't helping you.
If you're good at programming, you program frequently. Even with the knack, doing it a lot is the only way to get good. If you program frequently then you type a lot -- and in doing so become fast at it.
Cook and Atwood are both right. Cook correctly observes that your ability to program does not in any way depend on your ability to type quickly. Atwood correctly observes that that typing speed is a gambler's "tell:" if you haven't programmed enough to get fast at typing then however convincingly you talk the talk, odds are against you being very good at programming.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I usually write code, which I go back and modify.
More often than no, I reduce the size of the code. Not through using shorter variables or less programming. Rather, I find that there are commonalities which can be factored out. Also, I sometimes replace code with built in functions and libraries I did not know existed when I wrote things.
Even when writting English papers, I found that sometimes, I could clean things up after I get my initial concept down.
I have seen a lot of code written by other which was in terrible need of a rewrite, but it seemed as if people were more concerning in getting something done fast rather than elegant. I find that elegant code is easier to read, easier to maintain, and sometimes easier to debug.
I've met far too many programmers, barely half my age, who've already ruined their hands with poor keyboard technique. They've lost the ability to get into the actual code and have doomed themselves to cut&paste programming because their hands can no longer handle typing what they really need: they're forced to let the GUI do it for them, and the result is sometimes very poor code.
Modern IDEs tend to auto-complete
If you type reasonably well, auto-completion just slows you down. (Especially the really crappy implementation in OpenOffice Writer.)
Not only does typing speed help, but once you realize long variable names slows your coding down, you can even optimize for that. Conventional wisdom says to write long variable names to aid with documentation, and I agree, but there is a trade off between speed of typing and long variable names also. The faster you type, and the faster your compiler, the quicker you can revise and test code. It does matter, but it isn't the biggest factor in coding.
God spoke to me.
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.
I'm sure Stephen Hawking would be glad to make a comment about the correlation between typing speed and problem solving skills.
On average, good programmers write about 50 lines of code per day. I don't see how typing speed matters.
At first glance, it's easy to think of just code and say, "No, it doesn't matter." But then, I wonder what the code comment ratio is of programmers that average 80wpm+ to those that type much slower. Then consider that programming does often involve data entry.
Can someone show me how to figure out the typing speed of a programmer by looking at their code? If Atwood's prejudice is correct, we should be able to just look at a source file and see that it was written by a slow typist. We'd be able to score lots of open-source code by typing speed, and demonstrate whether it makes a difference in the program produced.
Summary fail.
Atwood's rant prompted John Cook to investigate...
One quote of Atwood's blog was taken out of context. Two short sentences != rant
From the comments, it is very painfully obvious that no one reads the article(s) anymore. Not even the submitter read the Atwood article, apparently. Atwood's blog post was about keyboards, not about the people using them. He made one passing remark about not taking touch typists seriously, using a lousy metaphor to pianists. Slashdot hating Atwood much?
Also, I found the Cook article to be rather boring and contrived. Arguing against a straw man is easy. "Someone says that slow typing makes you a bad programmer. THIS IS WHY HE IS WRONG!!!" ZOMGpwnzors. OK, the article wasn't that bad. But the /. comments about it are.
I've been studying CS for over four years and will finish up my master's in about a year, and I've never come across an exam where you need to churn out "large quantities of functional but utterly boring code".
I don't think I've ever had a computer-based exam. Labs, but they're generally not time-limited at my university at least, as long as you hand in the assignment on time and can explain the reasoning behind the code, you're fine. (with the only exception I've encountered being a course where we coded assembler on RISC-processors and a time limit was obviously necessary, but assembler is not very dependent on typing speed)
And usually not large quantities either, just code that accomplishes the task at hand, the less the better.
To be derisive of hunt and peck is nonsense in this context. I know a fair share of respectable speed typists not doing proper technique. Will they ever hit the 90+ WPM, perhaps not, but it really doesn't matter to that degree.
Speed only matters insofar as it gives an indirect indication of experience. If they are painfully slow, it means they haven't gotten much experience on a keyboard one way or another, which is a bad sign for a programmer. It's sort of a subjective measure, I'd guess 50 WPM ballpark would be what an experienced programmer would pull off if hunt and peck (I haven't measured lately, but I was 60 WPM when I did hunt and peck, probably no faster now even though I am using home row, but with dvorak).
XML is like violence. If it doesn't solve the problem, use more.
You can hunt-n-peck or you can touch-type to write code. Both do the job but one will make you into an insecure pussy.
If you are talking about user stories, SRDs, TRDs, etc, then typing may be quite useful at some point. OTOH there are people for that, like managers (they have to be good for something, especially project managers, lol).
But it sounded like the guy was trying to say that good typing speed was useful for PROGRAMMING, lol. What I am really saying is 'typing in code is a very small part of the job'. It should basically be pretty rote because yes by the time you put things into code they should be designed already, the tests should be specced out, etc.
I don't know if that makes me "old school" or not. I came up in the 80's. The thing is really when you are entering source code you aught to generally know pretty much what it will look like. There's plenty of 'tradecraft' in writing nice code, but the importance of coding is vastly overestimated, and as a result most software is crap these days.
I mean there's stuff I wrote that is keeping 747's in the air and such, large high volume trading systems, etc. Maybe for your average home project things are different, but no commercial software should really be getting written at a text editor or IDE to any appreciable extent.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
I have seen this repeatedly over the years... People who are slow typists or more generally are not proficient in using keyboard shortcuts or other features their editors / IDEs are more reluctant to certain kinds of changes to their code... i.e. small things like renaming, general cleanup, refactoring... They find it frustrating and so they make smaller changes with poorer results.
It may not be a big issue in general, but it obviously a hindrance to productivity and changes how someone things about the cost / benefit of making changes.
Come on, I hope you are joking.!
I would have my programmers to have time to actually think about what they were writing. What does it matter when it might take several days to come up with the solution to a problem. If your typing is that slow, you could hand off the code to a code monkey. What really matters is the quality of the code.
Duh. Programmers are compute bound, not I/O bound.
That world record typist may be able to type 10 times faster than Stephen Hawking, maybe even a thousand times faster, but you know what, he probably only writes those high level physics papers at less than one millionth the speed of poor slow typing Stephen.
Same with programming. It's the development of what you are working on in your head, not so much how fast you can input pure text. If you are a moderate typist and at least an ok programmer, doubling your typing speed probably won't increase output by more than 2 or 3 %. If you have a lot of raw data in non-digital form to input, you get the intern or keyboard operator to do that, and hope they don't typo anything.
It's kind of like a taxi driver and being skilled at driving at high speeds. Even if you can take the corners at a thousand mph without flipping the taxi, it won't really speed up how fast you can get your fare to the destination, unless you are driving on an empty Nascar track, and you know that will never happen in real life.
My typing speed then went completely to hell and my productivity dropped as well because I had to think about typing. After a few months my productivity returned to normal though I'll never get my typing speed back. You don't have to be able to take dictation. You just need to be able to type without thinking about it.
No, typing speed has nothing to do with programming ability. I still learned to program using pen and paper, drawing up flowcharts and data diagrams. Nowadays (after decades of practice) I can do a lot of coding in my head, while I'm out walking in the park or what have you. Typically I only need to be near a keyboard for an hour or so a day, when coding.
Typing speed is utterly irrelevant.
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.
Clearly the author is not living in the same world I am. Or anyone I know, for whom an extra hour a day would mean a significant and substantial boost in productivity or efficiency. One hour per day? For people who work 10 hours per day (to keep the numbers pretty), that would be an extra 10% productivity. For someone paid hourly, that's a raise of 10%. It's like getting more than an extra MONTH of work done every year. Or, flipped around, the ability to take an additional month of free time per year (more-or-less) and still get the same amount of work done or get paid the same annualized wage.
In my world, that's not something readily dismissed.
But, in reality most people wouldn't be able to type infinitely fast. And measuring the number of completed words, even with the posited factor of 2 for edits, is short sighted. Factoring things like email in addition to my programing output and paper writing output, and CLI typing on top of that, I'm probably closer to four or five thousand words per day. Although most of my time is still spent thinking, being able to reduce the time spent typing even by 20% would mean a lot. (Hell, I'm well on my way to talking myself into a bit of speed training.) The biggest boon, though, would be in being able to think faster since less of my time would be spend on starting and stopping my train of thought to type.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Typing speed is important: http://en.wikipedia.org/wiki/Infinite_monkey_theorem
Fast typing has very little importance to developers. However, anyone who spends the kind of time with computers as programmers will likely have at least moderately fast typing skills. So when we see someone hunt and peck, we generally presume that this person is not well versed in computers much less a programmer and it's probably true more than 99% of the time. In this day and age, kids are exposed to typing early so it's very unlikely they aren't familiar with the qwerty keyboard. But it's quite possible that they have sloppy technique where they make a lot of errors and have to use the back space a lot or they don't use all their fingers, especially the pinky.
The best thing to do when a person is starting out is to spend 2 weeks, 1 hour a day developing fundamental typing skills using a training program like Mavis. Sure it's a chore but the amount of pain you save in the long run is amazing.
And it applies to any job that requires written communication with other human beings.
I don't care if you do a 3 finger and thumb touch typing method, or an official secretarial typing pool approach as long as you're accurate and can do it without looking and you can do it faster than you can write it long hand.
If you spend all of your time looking for the letters on the keyboard, you will spend none of your time writing actual communication.
If you spend all of your time correcting your gross typos, you'll never proof read to check to see if your writings match your intended message.
I was encouraged to take typing in high school because 1) Being able to touch type over 35WPM helped keep my Dad firmly in the US during the Vietnam War (Let's here it for company clerks) 2) Being able to touch type helped supplement the family income while Dad was stuck in the Army.
As a side effect to being able to type I could spend more time doing research for school papers and proof reading to remove my faults with English grammar and spelling.
I could separate the concepts of content and markup which led to the most professional looking lab reports while I was at university.
However, being able to type fast is a tossup. On the one hand, it helps to be able to set an idea completely into hard copy before the finer details fade from memory.
On the other hand, with sufficient typing speed, one tends to type the same thing repeatedly instead of stepping back and thinking "Is there a more elegant way to implement this?"
I've done some programming now and then. Being able to type wicked-fast surely doesn't hurt. But, on the other hand, for a lot of problems it's easy to either write some super-verbose excessively lengthy hunk of code, or do it short and to the point. I've done some rapid-fire coding a few times but in most cases, it was thinking about WHAT to write and not a lot of actual writing. Of course, there are still those places that probably expect some number of lines of code still, and I don't know what to suggest about that.
When was the last time you saw a hunt-and-peck pianist?
Er, the last time I watched a friend *compose* a song on the piano, which is a better analogy. Hit some notes, write something down, hit some more notes, and so on.
This Atwood chap is a bit of a self important tool, isn't he?
Everybody seems to be missing a very important part of this: documentation writing. Banging out code is one thing. Using a code-completing IDE is another. But professional coders should be writing documentation including code comments, design documents, updating the project wiki, writing descriptions for version control commits, annotating bug tracking entries, using instant messaging and email, and whatever else. All of these things require typing skills.
The piano analogy is obviously completely wrong. Programming is not like playing an instrument. But, like any other professional, a programmer must be skilled with the tools of the trade, and the computer keyboard is the one tool that virtually every programmer uses.
There are some other posts that partially capture this thought. Really being able to type. Good keyboarding skills. This is nifty to have if you're a programmer, it's nifty to have if you're a writer, or have to create a lot of documentation, or various kinds of code. It isn't essential. It's not a measure of how good you are at any of those things. If you can achieve the accuracy you need, and you type fast enough that you don't find yourself taking shortcuts, using text-speak, giving all your variables names like S1 and A2 because you haven't the hand speed to call them something descriptive. Then it's not a big deal.
My coworker using some kind of bizarre sliding two hand eight-finger method two type that doesn't reliably use the same fingers to hit the same keys, and yet somehow she can type at very least faster than she can compose documentation or work instructions, and can even spell. (I Can't spell very well unless I can at least lay my hands on a desk and pretend to type the words.) I would expect anyone who is competent at any profession that requires spending a lot of time driving a keyboard to be at least a reasonably competent typist.
i actualy find this offensive. im a programmer and dyslexic so naturaly these things take longer to type out. to say someone isn't a programmer because they type slow is elitist
... because hawking did not have intellisense. nowadays we only need to type the 1st few characters of a word + it fills in for you so 150wpm is insanely faster than hawking
Programming is a craft. WPM or characters per minute mean very little. Is this even worth discussing?
We win together or suffer without.
I was trained to touch-type in Canada in 1988. I use almost exactly the fingerings described by your bottom diagram.
It's possible that I was merely a poor student, however I believe that is also how I was taught.
The one thing I *don't* do that I was taught is shift-hand alternation; i.e. right-hand shift with left-hand characters, and vice-versa. I tend to over-use the left shift key.
Do daemons dream of electric sleep()?
Actually, I'm going to have to disagree. The reality is that when people hunt and peck after many years of coding, it sometimes shows a deeper attitude of, "I can't be bothered." They can't be bothered to learn something other than VB, they can't be bothered to comment. They can't be bothered to use objects. They can't be bothered to learn the freaking API without re-inventing the .NET Framework. They can't be bothered to communicate...
So while I don't think 120 WPM is any better than 60 or even 40, I have definitely seen some other problems with hunt-and-peck typists (not all, but it's a red flag for sure).
Peter predicted that you would "deliberately forget" creation 2000 years ago...
I also use the bottom pattern. Also, I'm a left key shifter, exclusively. I could remove the right shift key an never, ever miss it. I hold the shift key solid and TYPE JUST ABOUT AS FAST as without. I almost don't need my pinky finger on my left at all really. I guess it makes me feel better about human adaptability too in a way.
If you can type fast, you can go through the write/debug/rewrite cycle faster. You can also actually test code in reality faster.
If you can't type, you'll either take longer to get the code entered and tested, or you'll have to desk check it, which may or may not be possible when you're dealing with other people's APIs.
Can you be a good programmer and slow typist? Sure. But if you can type fast your productivity will be improved.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
You don't have type 100 wpm to write good code, but if you type with two fingers, I have a hard time believing you know how to use a computer let along program one.
I only type about 35 WPM.. So I make my functions as concise as possible. In general, if typing speed is impaoring your ability to code, you're doing it wrong. Lines of code is a measure of maintainence cost, not programmer effiency
My brian is much slower than my ability to type most of the time. However there are times where I'm like ... come on fingers move faster I don't have all day.
On a subjective level it is very hard for me to take someone who hunts and pecks seriously. Objectivly my guess in most situations it makes little difference. It is possible although unlikely the lag could be productive in that it might force someone to think more about what they are typing or place a slightly higher premium on code reuse.
Better you type a few lines of bug free code each day spending hours on each line to insure perfection.
I was 50 wpm at my peak, without rushing. I considered myself a low-grade moron compared to some Windows programmers I knew because of their skill queueing up shortcut keys faster than the box could keep up. They knew the Windows menu structure cold (every programmer I ever met was like this on their own boxen), and could drill deep into arcana without a second thought. It used to be considered a mark of advanced skills, as observed by HR and MMgt types who couldn't tell the difference.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
The point seems to be being missed...
It's not that a good programmer must be a good typist, it's that a good programmer must spend a lot of time working with the keyboard, which in turn will turn them into a good typist.
Someone who's not a good typist can't have spent much time working with a keyboard, ergo does not have much practice programming, ergo is probably not a good programmer.
http://www.coolpicturegallery.net/2010/12/25-hot-girls-dressed-as-hot-video-game.html
While developers who type extremely slow make me roll my eyes.. what really annoys me is developers who are incapable of optimizing their daily work habits. The developer who repeatedly performs 10 steps to accomplish a task when a little work would reduce it to one step really flunk the IQ test as far as I'm concerned. When you ask them about it, they tell you they are too busy or simply shrug. That's just one task our of many.. A year later they are still doing 10 steps instead of one..
Have you fscked your local propeller head today?
this uber fast typist just demonstrated that faster isn't better by making such a stupid comment so fast he had no time to think through his position before it got posted ;p probably like most of his code, I code slowly and rarely need to correct or debug because I have time to think things through, by his lights the fact that I type slowly makes me a bad coder?, or that, in the day, mainframe programmers would send their hand-written code to data entry clerks for input means they wrote no code at all? ,speed is not proportional to quality, this is like (obligatory car analogy) saying the fastest car on the highway is driven by the best driver....that isn`'t normaly the case you know.
I find for coding or for my monthly columns/etc. I can't think faster than 60WPM, so I've learned to type at about 65WPM and that's good enough. Show me anyone that can code or write finished product at faster than 60 WPM ... and I'd HAPPILY hire them. Seriously: if you can create written product at 60 WPM (or faster), contact me at kurt@seifried.org.
If I want working, bug-free and maintainable code, I hire a programmer. Heck, if the programmer is good enough, it might even be worth it to hire a typist for him to dictate his code to.
Seriously ... expecting a programmer to hit 150 WPM is like expecting your carpenter to be the world champion in tree cutting.
See http://en.wikipedia.org/wiki/Keyboard_layout#US-International
I use a variant of that one, called AltGr International. It's the same layout, but without the dead keys. So you get the behaviour of a pure US layout, which is good for programming, and also the ability to produce diacritics just by pressing AltGr + <some key>.
So, I see your ß and also your æøåÆØÅ :-)
Hope that it helps.
a general problem of modern individualist society is to generally avoid any type of generalisation and generally scream upon any generalizing individual offering him not to think in so small dimensions anymore.
An old engineer retires after decades working in a factory. But some years after the factory machine breaks down and all the young engineers are baffled. Finally someone recalls the old engineer and asks him to come in, for a fee to see if he can fix it.
The engineer comes out of retirement and takes a look at the machine, walks to a part of it and hits it and the machine works again.
Everyone is happy, until the engineer sends his bill. $50.010.
The boss calls him, demanding to explain the charge for just one tap.
It is simple the engineer says: $10 for the tap. $50.000 for knowing WHERE to tap.
-----
The point is that there are workers and engineers. The workers should be judged on quantity, the engineers on quality. I myself have fixed small things that gave a tenfold increase in performance or dropped all errors from a system. What does that matter over building the original code? Well, 1/10th the server cost. A huge reduction in upset customers meaning less staff needed for support a huge recurring cost.
Who is worth more? The team that builds the car OR the one person who spots and fixed the fatal flaw with a gas pedal? Ask Toyota.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Right...
Next thing you're going to say is that you were allowed to use rulers to align your hand-written code on paper so that it is nicely stacked and nested.
Cause we all know that you must close your brackets in the same column you've opened them in, and may god help you if you haven't properly nested your loops - your computer might just explode in your face if you haven't done that properly.
Mit der Dummheit kämpfen Götter selbst vergebens
autocompletion types stuff for me.
He has not claimed that you have to be a fast typist in order to be a good programmer, but merely that a good programmer can almost always type quickly. According to the common "programming is to be learned in 10 years" saying, it is highly unusual to become experienced in programming without unwillingly getting a high WPM score in the meantime. It is understandable why one would not put much faith in a programmer that cannot type quickly, not because typing quickly is a requirement for being a good programmer, but because it inevitably comes with being a good programmer. The same thing happens with a pianist, with the exception that it is more important for pianists to be fast than it is for computer programmers.
Back when I first started with computers, we wrote our Fortran or COBOL code on 80-column coding sheets with a device known as a "pencil". These stylus-like instruments allowed us to write our code very quickly and quietly. Thus, a programmer could carry out his (or occasionally her) work with an air of dignity and repose no longer possible.
;-)
The actual typing was done by keypunch ops who could all type faster than 250 words per minute, no matter what the Guinness Book of Records might say.
http://en.wikipedia.org/wiki/Amdahl%27s_law
Computer scientist, Software engineer.
I'd say that the ability to type will correlate with the ability to code, after all, a person who codes a lot, and thus has a lot of experience, will have also typed a lot. Now, does this mean that all folks who type poorly are also bad coders? Not necessarily, but there is a strong tie.
Having said this, however, perception is reality. Managers, HR types, and potentially other folks who are not computer literate may very well have a lot of say in whether a person is hired for a particular coding job. I've seen some good sysadmins (yeah, not a programmer, but an IT professional none the less) who could not type well, and I would later have managers pull me to the side to politely ask if the person was good with systems. Of course, I spoke highly for them, and the managers never thought anything bad again. However, if I or someone trusted wasn't there to back them, I believe the manager may have taken actions to have the poor typists removed.
Say what you will about those poor typists or the "clueless managers" or whatever - yeah, the company might have lost out on some good sysadmins, however, those same sysadmins would have lost out on some good contracts. My point - impressions can count, and I've never seen a person's technical skills called into question due to good typing skills.
I'm not big on having my balls sucked (especially by guys), but this Jeff Atwood guy is clearly either very young or an idiot who only codes in toyland languages.
Back in the day, the only QWERTY keyboards on the Burroughs mainframes I had were the teletype devices used for a master console (or what Burroughs rather charmingly referred to as the SPO, or Supervisory Printer/Operator), and the action on those damn things was so damn stiff, not even God could have touch-typed on them.
Most of us evolved a heavy technique, mostly involving thumbs and two fingers on each hand. It's a hard habit to outgrow when you spend more time thinking than typing.
Some of my code of which I am proudest was entered in hex via the control panel on the front of the computer. Touch-typing not necessary.
-ding.
i can type pretty fast, but i cannot type code as fast as prosa. Too much symbols at second/third level and far away keys to type as fast as normal text.
But i think its good to be a fast typist, anyway.
I'm sorry, but I have to disagree with you. I'm coming at this from the perspective of a writer rather than a programmer (my last programming experience was in high school over fifteen years ago), but typing is an important skill here.
Now, will being a typist make you a better programmer? Absolutely. But not when it comes to thinking the code out. The place where typing is important is after the code has been thought out - the implementation. A programmer who does not know how to type will think the code out, and then have to find each key in order to input it into the program - it adds an extra step, and it takes longer. A programmer who is also a typist doesn't need to find the keys. The code flows smoothly from his head into the program via his fingers.
When it comes down to it, a good programmer must be skilled at both planning and implementation. Both are required. If you ignore the skill at implementation (aka not learning to type), you handicap yourself. The programmer who can both plan and implement clean and efficient code with speed will ALWAYS be of greater value than the programmer who can plan the code, but is slow to key it in.
Robert B. Marks
Author, Demonsbane in Diablo Archive
I don't think the difference between 60 and 100wpm matters in programming. But I've encountered the occasional hunt-and-peck programmer. And by hunt-and-peck I'm not referring to people who don't use home keys and have their own typing style. I'm referring to people who have to think about where on the keyboard the letter 'b' is located. It showed a lack of seriousness about their job and ultimately every one of them got fired or laid off.
People who are physically disabled are not the same as people who haven managed to somehow used their keyboard so little that they don't know where the keys are. I think it's a fantastic indicator of who the bad programmers are. You don't spend 8 hours a day typing at your desk without the ability to type 30wpm.
I type outrageously fast, english or code. However, about 25 to 66% of my keystrokes are wrong and need to be corrected.
I think that is common, but it is important (to me, anyway) to get the idea out of my brain and on paper AS FAST AS POSSIBLE before the thought leaves me. Can always correct later, but I can't always remember a great idea.
https://www.accountkiller.com/removal-requested
At my prior client, I burned 2 USB-controllers while typing. I discarted it as being just an issue with the age of the hardware.
Until now, where I've been given a top of the line workstation at my new job. 1 month in the job closing in on a deadline, another USB-controller burned out while typing.
Mind you, to make the deadline I typed slower in fear to burn my last USB-ports.
I think we can keep recursing like this until someone returns 1
I find it funny to watch someone who avoids using the mouse/gui typing, hitting tab, not getting he expansion they want, backspacing, typing again, hitting a tab, and so on, taking more time than it takes me to double-click a file icon in a window or paste in the name I copied earlier.
See also http://anarchycreek.com/2010/02/17/the-lump-of-coding-fallacy/
I'll second the laptop thing.
My work computer is a laptop. It's a laptop hooked up to a monitor, keyboard, and mouse, though, both at home and at the office.
When I actually have to use it as a laptop, I'm horrible at it. I've got a bluetooth mouse, I'd get a keyboard except a full sized one wouldn't fit in my laptop bag. (And I need a full sized one. I could do without the numeric keypad, but I need the arrow and page up/page down keys in the right place.)
Hell, I went out and bought a 'clicky' keyboard for home, just because that's what I'm used to. Had to buy a damn 70 dollar 'gamer' keyboard, but it was worth it.
I find it absurd that people who aren't comfortable with their typing can program as efficiently as people who are. I know that anything that slows down my typing has a major effect on my productivity as I start actually dealing with the fact I'm 'typing', instead of just the words magically appearing on the screen.
If corporations are people, aren't stockholders guilty of slavery?
So, according to Atwood, if you play piano very fast then you are a great pianist?
No, Jeff Atwood is just attention-whoring again. Since he quit his day job and became a full-time blogger the quality of his posts dropped to zilch.
I find it interesting that you find it more comfortable to reach up with your little fingers to hit the 2 and the 0 keys. To do that I have to pivot my hands so that my little fingers swing up and in to hit those keys. I find it a lot more comfortable, natural, and faster to hit the 2 and the 0 with my ringer fingers. All I do is reach up with the ring fingers, no pivoting of my hands.
I would say a hunt and peck programmer would be a red flag for inexperience. Anyone who has been programming for at least a couple years doesn't need to hunt and peck. If the resume says 5 years experience and they hunt and peck, I call BS. Does anyone know of a good programmer who still hunts and pecks?
How fast do you need to type if your only going to wind up with 10 to 100 lines of production code a day? "Great programmers spend little of their time writing code – at least code that ends up in the final product. Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. " - August 17th, 2010 David Veksler
Because it is poor programming skills will lead you to writing less readable code with a lot more shorthand, not poor typing skills.
The only thing typing skills affect is how long it takes you to write good code.
Writing obtuse code is a sign of a bad programmer, not a bad typist.
In other words, if a good programmer is a bad typist, the job will be done correctly, if slowly. If a good programmer is a good typist, the job will be done correctly and quickly. If you've got a bad programmer, it doesn't matter how fast he is, a good programmer will still have to fix all his mistakes.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
Well, it's not fair to say that. I type about 96 words a minute when I'm writing documentation. I think I tend to type a little faster when I'm coding. I often write 1000 or more lines of C++ code between compiles. It's because the code itself is just repetitive. I mean, I've been coding C++ for 20 years now, the code itself is a trivial aspect of programming. I tend to write my code as if it were written in SmallTalk as I haven't written a function in years which doesn't fit in a single screen. The only exception to this is in the rare case that a switch statement has a large number of possibilities, but even then, I'll attempt to categorize the elements to simplify it.
Coding is trivial. It should be the smallest part of a programmers job. While we'd like to think that with a lot more thought into planning, debugging won't be a bigger task, but in reality, debugging is often more time consuming than coding. One day when we're all perfect, that might change.
Planning is something a programmer should do when they're not coding. While writing on Slashdot. While eating lunch. While sleeping. While pretending to listen to their mothers nag on the phone about how they don't call or write. Personally, I'm 10 times more productive as a programmer while listening to an audio book and smoking a cigarette than when I'm actually typing. But, when I do sit down to type, I generally can do it as if I'm on an old fashioned typewriter and correction ink costs money.
Programming however is very individual. While there are a lot of people in the business world who would like to think of it as more of what a carpenter does, you know, buy the wood, but it and put it together from a plan. Programmers are generally a great deal more creative about how they solve problems. Each programmer has a different approach. Maybe someday, we'll have such great libraries for programming that it will no longer be necessary to think too much about how to accomplish a task, but for now, simply deciding how to integrate two libraries can be a creative work of art. Therefore, each programmer needs to do it differently.
I used to do my thinking between lines of code. It was VERY time consuming and I often found myself at the end in an integration nightmare scenario. Now that I think in much larger components, things go much more fluidly. And even when I find out after the fact that an entire module needs to be rewritten, often the module I had coded before hand can be reused at another time, so there's nothing lost.
Typing faster when coding is a great thing for many reasons. But, whether it is critical or not, well that's another story. I work with tons of 30wpm typists and frankly, my eyes want to bleed when I'm sitting next to them waiting for them too type something in. Though, sometimes it's a great time to get a coffee.
so I will respond to this thead, even though my response is largely irrelevant to the subject of the thread, and I will tell the world about MY JOB!
My mother is SO proud of me! I do code maintenance. Would you like to hear about ....MY JOB??
... if you are a touch typist you don't have to think about the typing - you can think about the programming instead.
it matters
a lousy programmer could inject more anti patterns and write more buggy software
the next on the line programmer will love it asfjklñasdfasdf
No one uses the "Esc" key: I like ^[ (ctrl-[) but others like ^c, both which work by default. bigger nerds remap caps lock to escape. I "imap jj " because I often write edit scripts to be piped in.
While at most half on home-row, Control-[ is a much smaller stretch than Escape which is so far up the left side you probably can't hit it without moving your entire left hand.
Anyone who breaks programming down into 'typing' doesn't know what the hell programmers should be doing.
The Kruger Dunning explains most post on
I don't see how your typing is better if it's not faster. I've been touch-typing for over twenty seven years without wrist problems. Posture is important.
Cool if it works for you of course. But the list of people with typing problems is pretty long.
"If a novelist writing 1000 words per day were able to type infinitely fast, he or she could save maybe an hour per day."
1 hour / day * 260 work days * hourly contracting rate of $100 = $26,000
It's logical to say that's at least five figures a year you could save as a business.
Sure, I've worked with good coders that are lousy typists. And I've yawned as I rode shotgun & pair programmed with them, waiting for them to physically crank out the work needed to be done on the keyboard.
Pair programming is far bigger a waste of $$$ versus typing speed. Throw in slow typers + pair programming, and you've got a cost-inefficient mess some agile companies are quite proud of.