Does Typing Speed Really Matter For Programmers? 545
theodp writes "I can't take slow typists seriously as programmers,' wrote Coding Horror's Jeff Atwood last fall. 'When was the last time you saw a hunt-and-peck pianist?' Atwood's rant prompted John Cook to investigate just how important it is to be able to type quickly. 'Learning to type well is a good investment for those who are physically able to do so,' concludes Cook, 'but it's not that important. Once you reach moderate proficiency, improving your speed will not improve your productivity much. If a novelist writing 1000 words per day were able to type infinitely fast, he or she could save maybe an hour per day.' At 150 WPM, notes Cook, the world's fastest typist was still only 10x faster than Stephen Hawking."
it matters for first post! (Score:5, Funny)
text is one thing, symbols quite another (Score:2, Insightful)
Put another way, watch your error rate jump up when you quit posting on Slashdot and go back to your day job... if you have one, that is.
Re: (Score:2)
Enter vim, you rarely need to remove your fingers from the home row. ;)
But I don't think it matters much, maybe if all you're doing is copying someone elses code without thinking about it. In most cases thinking about the problem at hand takes a lot more time than actually typing the code..
Re:text is one thing, symbols quite another (Score:5, Insightful)
Except, you know, every three seconds, unless you have remapped your keyboard so that the most important command in vim is not assigned to the far top left corner of the keyboard.
More important - having a Model M (Score:5, Funny)
Re: (Score:3)
I prefer Apple's aluminum keyboard. You can slice your rivals' heads off with one fell swoop.
- Jasen.
Re: (Score:2)
Fast Well (Score:3, Interesting)
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.
Re: (Score:2)
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 rath
How Absurd (Score:5, Interesting)
'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.
Re:How Absurd (Score:5, Insightful)
Re: (Score:2)
Actually, the more you type and the less you pause to think the more likely what you type will have to be scrapped later.
I can do something as 15 loops one under another. Or I can find a pattern in what these loops are similar to each other and write the code as two nested loops. Surely fast typing would make writing the 15 loops easier...
Re:How Absurd (Score:4, Interesting)
But once you've thought about what you want, it helps to be able to touch type instead of hunt&peck. It lets you follow the path that much more smoothly.
I'd say though, that it's not so much typing speed as much as the ability to touch type, no matter how fast, that matters.
Re:How Absurd (Score:4, Interesting)
Re:How Absurd (Score:5, Insightful)
Re: (Score:2)
There could be a business opportunity there. In order for your program to work I need to be in my office typing in all those dialogue messages as they are displayed. My rates are...
Re: (Score:3)
Another argument: Pair programming increases code quality. Surely two people sharing one keyboard doesn't increase the typing speed.
Re: (Score:2)
Re:How Absurd (Score:5, Interesting)
Re: (Score:3)
Best comment in the whole thread. Unfortunately, I'm posting instead of modding.
Anyway, all the naysaying repsonses probably (for the most part) be judged to be slow typists sour grapes.
After all, why would someone who knows how type disparage the ability to do so?
It's like a knowledge worker who claims he mainly just "thinks" and doesn't need to know how to write. Typing is the ability to computerize your thoughts after you're done thinking.
Re: (Score:3)
I call bullshit.
Most programmers can touch type (hitting at least 50 wpm, which is only 1/3 the speed of the fastest typist in the world), yet most code is lacking in detailed comments and meaningful symbol names.
Someone who types quickly thinks very little of writing a few lines of documentation at the start of each function and of providing comments with full sentences explaining why various approaches were chosen.
I couldn't have said it better myself. Quick typists apparently don't think about what they type, and just splatter shit all over the place. Making code hell to understand
A slow typist, however, cares a lot more about each and every word they type, so the code is far more likely to be concise (no
Re: (Score:3)
Re: (Score:3)
I don't believe that it was insinuated that there was a linear relation between WPM and code quality. Yet, there is a clear connection between coding experience and the time spent hacking away on a keyboard. Therefore, if someone happens to be unable to type at a reasonable speed then that person certainly hasn't spent enough time in front of a computer, and at best only a fraction of that time deve
Re:How Absurd (Score:4, Interesting)
You are completely correct, it's completely absurd, especially in specialised disciplines. You know how you can tell when I'm programming? I'm sat in the office with my feet up throwing a ball in the air. Thinking.
Re: (Score:2)
But after several years of coding you probably got enough typing practice to have some decent typing speed anyway.
Re: (Score:2)
Programmers that type quickly are more prone to write one off disposable programs, and hence are just more practiced.
Sounds more like an issue with dedication than anything else. Being able to type at a reasonable pace should be all you need. I don't know about anyone else (though other people did mention it), but when I'm programming, I tend to stop and think about the most efficient way to implement something. Most of my time isn't wasted on typing, but on that. Being able to type slightly faster likely won't make much of a difference.
Re: (Score:2)
Correctly as in securely, efficiently and in a way which I can read later on. Fast typing is from my point of view somewhat counter productive as short burst of flurry don't
Not really important if somewhat proficient (Score:4, Insightful)
It does help a little to have some typing speed, but haste makes waste.
The most important factor in programming is not speed, but solid code. If you write lots of code, but the code is buggy, the time to track the bugs will easily eat any time savings gained by speed.
When it comes to debugging, thinking through the problem before trying to trace solve it will save more time then faster typing in the debugger. If by careful analysis, you can rule out 90% of the area of the problem, you have just reduced the time to track the problem by 90%.
Re: (Score:2)
A moderate typing speed suffices. Say, oh, 30wpm, or thereabouts?
If you're not typing at a reasonable speed, you're going to have an incentive to shorten variable and function/method names from something reasonable to something cryptic. You're going to avoid typing documentation, or worse, propose that your cryptic POS code is 'self documenting'. You're going to be an unpleasant partner if you end up pair-programming. All this means you're not only affecting /your/ productivity, but you're now negatively a
Re: (Score:2)
And really, if you can't do at least 50 WPM, you really shouldn't be bragging about your typing speed, at least not anywhere that anybody that uses a keyboard on a regular basis might see you doing so.
Practically Immaterial (Score:4, Insightful)
If you're spending most of your time as a programmer typing, or even dealing directly with source code, then there's a lot more wrong with this picture than typing speed. Keying in code should be one of the most trivial parts of the job.
I'd say being able to type well will probably improve ones enjoyment. It may save a few minutes here and there. It is certainly annoying to watch someone else type slowly when you're waiting on something. Still, it has little or nothing to do with one's ability to program or ability to complete coding tasks quickly and well.
Code monkey or engineer? (Score:4, Insightful)
Don't measure WPM (Score:5, Insightful)
output = "We";
output += " should";
output += " really";
output += " be";
output += " measuring";
output += " lines";
output += " of";
output += " code";
output += " per";
output += " minute.";
System.out.println(output);
Re: (Score:3)
Re: (Score:2)
It's *thinking* faster that counts (Score:2)
Re: (Score:2)
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.
Yes, but that thinking doesn't necessarily happen while constantly staring at the monitor, nor it occurs uninterrupted until you discover the meaning of life. Beyond required phases of analysis and design, or as a response to inevitable interruptions to one's thinking muse, we do a lot of prototyping and experimentation. There is this thinking process that occurs by tinkering and exploring. Barring areas of high criticality, software development is a highly iterative process that involves bout of (sometimes
Re: (Score:2)
Programming != Data Entry (Score:4, Insightful)
Programming is the same. I would much rather a programmer actually put more thought into algorithms and design than churning out code. Ultimately what does it matter how many WPM a programmer can program anyway? Half the time they will spend their team using obscure symbols on the keyboards and actually reading / looking at cross-references and algorithms than actually punching in words. Even if a programmer can't churn out 50WPM does it matter providing he's reasonably fluent and doesn't spend 1 minute looking for the ! symbol?
Re: (Score:2)
Programming is the same. I would much rather a programmer actually put more thought into algorithms and design than churning out code.
the thing is, often you do need to write boilerplate-ish code (think unit tests), or code where you know EXACTLY what you want to do already, so maximal coding throughput is still very important: very few people spend their working time writing code where every line requires a lot of thought, most people will write code where maybe 20% of it is non-trivial and requires a lot of investigation, and 80% is "trivial" code to support the 20%. The more experience you have the more likely the ratio skews towards "
Re: (Score:2)
Re: (Score:2)
I sort of agree but the analogy used by Jeff Atwood isn't perfectly suited for the situation.
Imagine that the pianist is trying perform a piece of music. That's the "creating a program" part expressed as "creating a musical performance". Now imagine that this pianist can never remember where the different keys are, do you think the performance he is able to put together is anything like the performance put together by a second pianist who "just knows" what key to press while reading the sheet music?
Another
Re:Programming != Data Entry (Score:5, Insightful)
A pianist is the equivalent of a data entry clerk. They have a sheet in front of them and faithfully reproduce what's on it.
Not quite. Once you move beyond entry-level competitions, it's simply a given that anyone and everyone can play anything given to them flawlessly. Your performance is judged on how you interpreted the piece, not merely on the fact you can read sheet music.
For example, listen to Rachmaninoff [youtube.com] playing his Prelude in C# Minor versus a newer interpretation [youtube.com]. Especially compare 1:58 in Rachmaninoff's piano roll with ~1:20 in Peter Roper-Curzon's version; there's a lot going on beyond technical accuracy.
I don't type very fast when I'm coding (Score:4, Informative)
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.
Re: (Score:2)
I'm the same way.
The other day while coding I realized that I was typing waaaay faster than I normally do while typing.
Then I realized that it was because I was writing an IM.
After that I went back to coding and my typing slowed down tremendously.
Thinking about this, it's probably because over time I've learned that it saves a lot of time to slow down and consider the structure that you are creating when coding, and making sure that you have very few typos/switched variable names. Sometimes the tools can he
Correlation:typing speed and coding experience (Score:5, Insightful)
There is a reasonable basis to assume that a slow typist is not a decent coding. After all, typing speed is something which is naturally developed as the person keeps hammering away at the keyboard. So, although typing speed does not guarantee coding proficiency, if someone does not pass enough time in front of a keyboard to develop any decent speed then it is expected that that person hasn't spent much time writing software. And if someone hasn't invested all that time writing code then quite certainly that person sucks at coding.
Re: (Score:2)
This actually makes sense, and explains why typing speed doesn't cause good programming, but there might still be a correlation.
Re:Correlation:typing speed and coding experience (Score:5, Insightful)
There is a reasonable basis to assume that a slow typist is not a decent coding. After all, typing speed is something which is naturally developed as the person keeps hammering away at the keyboard. So, although typing speed does not guarantee coding proficiency, if someone does not pass enough time in front of a keyboard to develop any decent speed then it is expected that that person hasn't spent much time writing software. And if someone hasn't invested all that time writing code then quite certainly that person sucks at coding.
For my own personal case, I was a typist for about 8 years before I went down the coding path so my views might be a bit skewed and subjective.
With that out of the way...
I would tend to agree that there is a correlation of typing speed and software development experience (or there should be for a proficient programmer with a shitload of coding man-hours.) A person that doesn't spend enough time coding will simply code at sucking. And if that person does not have typing skills a-priori then that person will not have good typing skills. So, it is fair to assume that a person that works as a programmer should have decent typing skills, not because he/she needs them for coding, but as a side-effect of programming exposure, in a manner proportional to the amount of work hours doing coding.
That is, I would see it as suspect to see a programmer that cannot type proficiently, be it with all 10 fingers or simply with their index fingers. And I would not reserve that suspicion only to senior programmers but even to fresh-out-of-school ones. Not just good, but passionate CS/MIS students (either BS or AS degree seekers) will have sufficient coding hours under their belt to inevitably develop some typing dexterity. Passionate art students paint and sculpt a shitload. Passionate electrical engineers spend a shitload of hours building circuits. Passionate CS/MIS students spend a shitload of hours coding. In all cases, it is a shitload of hours beyond the minimum requirement to get a degree.
Will lack of typing dexterity mean with utmost infallibility that someone sucks at coding (or that was a slacker in school)? Obviously not. But it would be hard not to see it as suspect.
Another thing is that yes, typing dexterity helps with coding, with prototyping, with hacking. Yes, we need to plan and design before we code, but when you know exactly what needs to be done, or when you have a sufficiently good idea to start prototyping (or when you are in the middle of a hack that *must happen*), bro, you better be able to get those streams of thought fluently down to your keyboard via your fingers. If you have done coding work for real, getting down to some really nice (or ugly but necessary) code, you know what I mean - that you are in your mojo coding that thing down.
I cannot imagine getting myself into that *zone* of coding while struggling with the keyboard. No way, no how. I cannot see how someone could get into that *zone* without good typing skills. Period.
You don't need typing skills for design. But you certainly need it to crank some code when the muse inspire you. And if the muse doesn't inspire you often, you are either in the wrong career choice, or you suck.
Re: (Score:2)
Still, at my 4-finger-combo, I can type moderately fast while creating correct code. I've seen kids who could touch-type faster than me, but didn't even know what programming is all about.
Re: (Score:3)
You are wrong.
An analogy is to compare a gourmet and a bulimic.
Typing fast is similar to eating large quantities of food in the fastest way, instead of appreciating the food you eat.
At my work, we have a super slow typist, and since we code with pair programming, when I worked with him, I wanted to take the keyboard, since he was so slow.
However, there are several points that were more important than speed:
1) the IDE (we use Visual Studio and Resharper) slows down the typing, because of the "Intelli
Its the Cognitive Load (Score:5, Insightful)
Its not the speed of the typing that matters, its the cognitive load. If you're spending all of your time trying to remember where the '}' key is, then you'll find it hard to keep your loop invariants invariant in your head. This leads to bugs.
If you type with two fingers, but can do it without looking or thinking about anything other than your code, then it doesn't much matter how fast you go. On the other hand, if you achieve incredibly coding speed by concentrating on your fingers, your code is sure to suffer.
Re: (Score:2)
Re: (Score:3)
I was going to post exactly this, but you beat me to the punch. There is another factor too, though. If you struggle to type, you're more likely to use brief, cryptic, incomprehensible identifiers in your code, and to omit even the most minimal of comments, creating major long-term headaches just to save yourself some short-term pain. In my experience, there is a minimal threshold below which I wouldn't want a programmer, because I simply wouldn't trust 'em to produce maintainable code, but I think it's
Typing speed is very important, however... (Score:2)
... "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 th
No (Score:2)
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.
Re: (Score:3)
what about mental load of slow typists (Score:2)
Yes, and no... (Score:5, Interesting)
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.
it. certainly. does. when. you're. waiting. on. (Score:2)
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.
Comment removed (Score:5, Insightful)
Re: (Score:2)
Consequently, while it might be nice to type really fast, the reality is that you can't do it because you simultaneously need to be making sure you're typing the correct code. A similar problem to computer processors, they could do a lot more calculations if we were OK with the calculations not being
Re: (Score:2)
The answer is "No" (Score:5, Interesting)
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.
Re: (Score:3)
Good point. We might even take more points from him for his flawed argument than for another's slow typing. :-)
Yes (Score:3)
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..
More important: Knowing the English keyboard (Score:5, Insightful)
Frankly, I can deal with programmers who are "slow" typists. Within reason of course, but in general, unless they're coding in Pascal (and even then, they will probably have learned by now how to quickly type those 'begin's and 'end's) or another language more suited to writing novels than code, what big difference will it make provided they know how to code?
What matters to me is their ability to use an English keyboard layout and do not have to insist in their own language. This becomes especially obvious in a multi language team (i.e. where English is the language of choice even if nobody has it as his native language because, well, it's the ONLY language they share), where you might be forced to use someone else's machine for something only to find out that you can't find ANY important characters because they're conveniently tucked away somewhere safe.
But more important, have you ever noticed how all those important brackets and punctuation that you NEED in 99% of the languages are near impossible to type without breaking your fingers on non-English keyboard, especially if that language has to deal with a lot of diacritical characters? On most non-English keyboard the { and } brackets are only reachable with the combination of Alt-GR and 7-0. And let's not even talk about the "Polish writing keyboard layout", which is a nightmare to program with. I still think they did it on purpose, I cannot imagine that anyone could actually code using such a layout.
If you are programming, and you happen to "suffer" from one of those layouts, try switching to an English layout. When I started to code, I was wondering who the FU.. could come up with the idea that { and } would be sensible to use for something you need, like, every other character. Once I switched to English, it started to make sense.
Re: (Score:3)
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.
Agreed. I switched to a UK layout about 10 years ago, as I was living in the UK and started programming more seriously. In retrospect I wonder how I managed to use Linux, including shell scripting, HTML, latex etc. with a Finnish keyboard prior to that. For typing in Finnish, there is fortunately a way for fast switching in Xorg.
As for typing speed and programming, there are also things like comments and documentation. For these it is great if you can write extended natural-language text without frustrat
Re: (Score:2)
Man, what an ethno-centric, you're the kind that gives Americans a bad reputation.
1) My native language would be very annoying to write on a US keyboard. Try finding the alt codes for æøåÆØÅ if you don't believe me.
2) I know where all the symbols are in my layout, trying to use two layouts is like if I'd randomly switch your keyboard between dvorak and qwerty.
If you're going to use multiple keyboard inputs, you can easily configure a computer to work that way. There's a little
Re:More important: Knowing the English keyboard (Score:4, Interesting)
1) I'm not from the US. My native keyboard contains no æøåÆØÅ but instead öäüÖÄÜ and I raise by an ß. May I still play? Btw, we use QWERTZ instead of QEWRTY, just to make things more interesting. And I'm kinda sure that your standardization bureaucracy found a neat way to substitute those æøåÆØÅ characters like we did with oe for ö and ue for ü, etc. It's hardly impossible to emulate those characters without having an ASCII-table crib sheet.
2) Of course I do know where all the symbols are on my native keyboard layout. I learned typing and also programming using one. And yes, with the more recent Windows and Linux versions it became easier to actually switch between layouts, which is why I do now definitely recommend switching to a US layout for programming, since it is trivially easy to switch to and fro between "programming" and "writing" mode.
If you read my post again without the implicit imagination that I'm trying to press for some US-centric keyboard layout imperialism, you might notice that I wanted to show that it becomes heaps easier to program using a US keyboard layout, and you don't break your fingers every time you're supposed to type { or }, or pretty much anything else you need for "normal computer operation". Oh, btw, on my native keyboard, the backslash is AltGr-ß. What's more irritating even is that @ is AltGr-q. Do you know how irritating it can be to accidentally hit AltGr-Tab instead on a Windows machine? Compare that to the fairly uncomplicated handling on a US keyboard.
Makes sense now?
It might be of importance if you are studying... (Score:2)
...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. [youtube.com]
10 times more tired (Score:2)
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
Quality vs. Quantity (Score:2)
Re: (Score:2)
I work with someone like that. He hits a lot of keys in a very short period of time... but almost half of them are the backspace key, because he almost never hits the key he wants to hit.
It sounds like he's getting a lot of work done. If you look over his shoulder, you might find out he's spent the past five minutes trying to scp his editor's configuration file from one machine to another.
it matters a lot (Score:5, Insightful)
Touch typists generally use more verbose variable names and more comments, because it's much more natural for them to type a lot of words. This makes their code a lot more readable, which saves money in the end since a *lot* of the cost of software is in maintenance and the only performance factor that really counts is not cpu cycles, memory usage or bandwith utilization, but euros, dollars, rupees, yens or whatever your legal tender is. The programmer's time is (one of) the most costly aspect(s) of software development. A crufty codebase is much easier to read and maintian with comments *really* explaining fixes and variable names explaining what they're used for. I see so much code with comments like '// Issue #24654' or variable names like 'i' or 'j' in functions that span more than 50 lines (or whatever fits in one screen).
Of course there's more than typing speed involved in making maintainable code and I'm sure there are non touch typists who force themselves to make their code readable, but being able to type fast without thinking helps a lot.
WPM Important... But Not For Programming (Score:2)
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 mad
indicator of passion (Score:2)
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.
You're looking at it all wrong... (Score:2)
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.
Is it a cultural thing? (Score:2)
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. B
SMBC is right again (Score:3)
Fast typing has helped me sometimes (Score:2)
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 o
What about disruption of thought? (Score:2)
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
Re:Depends on what language you use (Score:4, Interesting)
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.
Re: (Score:3)
The problem lies in the mentality 'I'm a java programmer, *therefore* I use an IDE with autocompletion'.
Re: (Score:2)
i wonder if there are java ides that automatically *fold away* all the declarations they autocomplete for you? just how succinct would java be if all of its automatically-generated-by-the-ide verbosity was also auto-hidden from you, until you decided to look under the hood?
is there an elegant language hidden beneath the layers of machine-generated noise in java?
Re: (Score:2)
well, there's groovy for that.
Re: (Score:2)
Re: (Score:2)
This is not an argument FOR java. This is an argument against it.
Re:Depends on what language you use (Score:5, Insightful)
You can have that in any language.
It is simply a matter of choice. Most C/Perl people I know chose to have autocompletion off as it is not particularly useful (aside from getting braces right). C++ is on the fence. Most of Ruby developers I have worked with are definitely in the "my IDE types 2/3rds of the code for me" camp.
IMHO if your IDE is typing 2/3rds of what needs to be typed without getting it wrong then there is something fundamentally wrong with the language. The autogenerated verbosity simply does not need to be there in that case.
Re:Depends on what language you use (Score:5, Insightful)
I don't think so. I think it's something fundamentally wrong with the language if the IDE can't get 2/3rd of the typing right for the developer.
Take dynamic typed languages like Python, Groovy. Half the time I need to look up what the type is and what methods are there to use instead that the IDE is just auto complete it for me. With C++ you have static typing but the language is so complex that auto completion is almost useless.
I'm not a language purist. If the code is verbose but helps the IDE/compiler to understand the code better so the IDE can generate 2/3rd of my code for me why should I care about the verbosity? Actual, sometimes verbosity is a good thing, it helps to read the code and understand it later.
Re:Depends on what language you use (Score:4, Interesting)
> 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.
Re: (Score:3)
Re: (Score:3, Insightful)
IMHO if your IDE is typing 2/3rds of what needs to be typed without getting it wrong then there is something fundamentally wrong with the language. The autogenerated verbosity simply does not need to be there in that case.
Really depends on the type of autocompletion, IMHO.
I'll take (reasonably) verbose variable, function and class names over unix-C-style abbreviations any day - but it does require an IDE with decent autocompletion if you don't want to go insane... But given a decent IDE with "camelhumps" style autocompletion you end up typing less than the unix C programmer, while getting clearer source code.
I find that I spend a lot longer thinking about code architecture than on actual typing - even if using Notepad++ inst
Re:Depends on what language you use (Score:5, Insightful)
Most of the work do is maintenance. Finding bugs in 20 year old code. If I change two characters in one line on one day and close one bug, then thats a good day.
Re:Depends on what language you use (Score:4, Funny)
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.
Re: (Score:3)
The challenge is finding the bugs
Mod parent up (Score:3)
You are not a professional programmer until you realize that most the work is debugging.
Re: (Score:3)
Re: (Score:2)
You think C++ is more concise than Java?
It is to laugh.
Perl... now Perl isn't always terribly friendly on a touch-typist. But maybe that's just because I haven't mastered the opposite-hand-shift like I should.
Re:Depends on what language you use (Score:5, Insightful)
A wall of symbols isn't preferable when you're trying to understand the algorithm that the programmer has implemented.
Re: (Score:2)
Actually, there should only be one key - "Do What I Want" key.